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Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Digital Enhanced Cordless 
Telecommunications (DECT). 

The present document is based on EN 300 175 parts 1 [1] to 8 [8] and EN 300 444 [12]. General attachment 
requirements and speech attachment requirements are based on EN 301 406 [11] (replacing TBR 006 [i.2]) and 
EN 300 176-2 [10] (previously covered by TBR 010 [i.3]). Further details of the DECT system may be found in 
TR 101 178 [i.l]. 

The present document has been developed in accordance to the rules of documenting a profile specification as described 
in ISO/IEC 9646-6 [i. 14]. 

The information in the present document is believed to be correct at the time of publication. However, DECT 
standardization is a rapidly changing area, and it is possible that some of the information contained in the present 
document may become outdated or incomplete within relatively short time-scales. 

The present document is part 3 of a multi-part deliverable covering the New Generation DECT as identified below: 
Part 1: "Wideband speech"; 
Part 2: "Support of transparent IP packet data"; 
Part 3 : " Extended wideband speech services ' ' ; 

Part 4: "Light Data Services: Software Update Over The Air (SUOTA), Content Downloading and HTTP based 
applications"; 

Part 5: "Additional feature set nr.l for Extended wideband speech services". 
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1 Scope 

The present document specifies a set of functionalities of the New Generation DECT. 
The New Generation DECT provides the following basic new functionalities: 

• Wideband speech service (part 1 [21] of this multi-part deliverable). 

• Packet-mode data service supporting Internet Protocol with efficient spectrum usage and high data rates (part 2 
[i.4] of this multi-part deliverable). 

• Extended wideband speech services (the present document). 

• Light Data Services: Software Update Over The Air (SUOTA), Content Downloading and HTTP based 
applications (part 4 [i.5] of this multipart deliverable). 

• Additional feature set nr. 1 for Extended wideband speech services. 

Additional functionalities of the New Generation DECT may be defined in the future in further parts of this multi-part 
deliverable, or in different documents. 

All New Generation DECT devices will offer at least one or several of these services. 
The present document describes the part 3: Extended wideband speech services: 

• For the description of the wideband speech service, see TS 102 527-1 [21]. 

• For the description of the support of transparent IP packet data, see TS 102 527-2 [i.4]. 

• For the description of the Light Data Services: Software Update Over The Air (SUOTA), Content 
Downloading and HTTP based applications, see TS 102 527-4 [i.5]. 

• The description of the additional feature set nr. 1 for Extended wideband speech services will be published as 
TS 102 527-5 [i. 13]. 

Part 3 ("Extended wideband speech services") is defined as an extension of part 1 ("Wideband speech" [21]), which 
means that all devices compliant to the present document will also implement at least all mandatory features and may 
implement the optional features defined in part 1 . In addition to that, the present document defines additional mandatory 
or optional features. 

Part 1 [21], and therefore part 3, are also defined as extensions of the "Generic Access Profile (GAP)" [12]. All DECT 
devices offering Wideband speech services (part 1 or part 1 plus part 3) are also compliant with the "Generic Access 
Profile (GAP)" [12], and offer the DECT standard 32 kbit/s voice service according to GAP [12]. 

All DECT devices claiming to be compliant with this Application Profile will offer at least the basic services defined as 
mandatory. In addition to that, optional features can be implemented to offer additional DECT services. 

The aim of the present document is to guarantee a sufficient level of interoperability and to provide an easy route for 
development of DECT wideband speech applications, with the features of the present document being a common 
fall-back option available in all compliant to this profile equipment. 
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2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
referenced document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox. etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 



2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[I] ETSI EN 300 175-1: "Digital Enhanced Cordless Telecommunications (DECT); Common 
Interface (CI); Part 1: Overview". 

[2] ETSI EN 300 175-2: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 2: Physical layer (PHL)". 

[3] ETSI EN 300 175-3: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 3: Medium Access Control (MAC) layer". 

[4] ETSI EN 300 175-4: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 4: Data Link Control (DLC) layer". 

[5] ETSI EN 300 175-5: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 5: Network (NWK) layer". 

[6] ETSI EN 300 175-6: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 6: Identities and addressing". 

[7] ETSI EN 300 175-7: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 7: Security features". 

[8] ETSI EN 300 175-8: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 8: Speech and audio coding and transmission". 

[9] Void. 

[10] ETSI EN 300 176-2: "Digital Enhanced Cordless Telecommunications (DECT); Test 

specification; Part 2: Audio and speech". 

[II] ETSI EN 301 406: "Digital Enhanced Cordless Telecommunications (DECT); Harmonized EN for 
Digital Enhanced Cordless Telecommunications (DECT) covering the essential requirements 
under article 3.2 of the R&TTE Directive; Generic radio". 

[12] ETSI EN 300 444: "Digital Enhanced Cordless Telecommunications (DECT); Generic Access 

Profile (GAP)". 

[13] Void. 

[14] Void. 

[15] Recommendation ITU-T G.726 (1990): "40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code 

Modulation (ADPCM) ". 

[16] Recommendation ITU-T G.71 1 (1988): "Pulse code modulation (PCM) of voice frequencies". 

[17] Recommendation ITU-T G.722 (1988): "7 kHz audio-coding within 64 kbit/s". 
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[18] Recommendation ITU-T G.729. 1 (2006): "G.729-based Embedded Variable bit-rate coder: An 8- 

32 kbit/s scalable wideband coder bitstream interoperable with G.729". 

[19] Void. 

[20] ISO/IEC JTC1/SC29AVG1 1 (MPEG): International Standard ISO/IEC 14496-3:2009: 

"Information Technology - Coding of audio-visual objects — Part 3: Audio". 

[21] ETSI TS 102 527-1: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 1: Wideband Speech". 



2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TR 101 178: "Digital Enhanced Cordless Telecommunications (DECT); A high Level Guide 

to the DECT Standardization". 

[i.2] ETSI TBR 006: "Digital Enhanced Cordless Telecommunications (DECT); General terminal 

attachment requirements". 

[i.3] ETSI TBR 010: "Digital Enhanced Cordless Telecommunications (DECT); General terminal 

attachment requirements: Telephony applications". 

[i.4] ETSI TS 102 527-2: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 2: Support of transparent IP packet data". 

[i.5] ETSI TS 102 527-4: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 4: Light Data Services; Software Update Over The Air (SUOTA), content 
downloading and HTTP based applications". 

[i.6] Recommendation ITU-T P. 31 1 (2005): "Transmission characteristics for wideband (150-7000 Hz) 

digital handset telephones". 

[i.7] Recommendation ITU-T G.729: "Coding of speech at 8 kbit/s using conjugate structure algebraic- 

code-excited linear prediction (CS-ACELP)". 

[i.8] Recommendation ITU-T Q.23 (1988): "Technical features of push-button telephone sets". 

[i.9] Recommendation ITU-T Q.24 (1988): " Multifrequency push-button signal reception". 

[i.10] Recommendation ITU-T E.180 "Technical characteristics of tones for the telephone service". 

[i.l 1] Recommendation ITU-T E.180- Supplement 2: "Various tones used in national networks". 

[i.12] Recommendation ITU-T E.182: "Application of tones and recorded announcements in telephone 

services". 

[i.l 3] ETSI TS 102 527-5: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 5: Additional feature set nr. 1 for extended wideband speech services". 

[i.14] ISO/IEC 9646-6: 1994 "Information technology - Open Systems Interconnection - Conformance 

testing methodology and framework — Part 6: Protocol profile test specification". 

[i. 15] ISO/IEC 9646-7: "Information technology — Open Systems Interconnection — Conformance 

testing methodology and framework — Part 7: Implementation Conformance Statements". 

[i. 16] ETSI TS 122 072: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Call Deflection (CD); Stage 1 (3GPP TS 22.072 
version 9.0.0 Release 9)". 

[i.17] ETSI TS 122 081: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Line Identification supplementary services; Stage 1 
(3GPPTS 22.081)". 
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[i. 1 8] ETSI TS 122 082: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Call Forwarding (CF) Supplementary Services; 
Stage 1 (3GPPTS 22.082)". 

[i. 19] ETSI TS 123 082: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Call Forwarding (CF) supplementary services; Stage 2 
(3GPP TS 23.082)". 

[i.20] ETSI TS 124 082: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Call Forwarding (CF) supplementary services; Stage 3 
(3GPP TS 24.082)". 



3 Definitions, symbols and abbreviations 
3.1 Definitions 

For the purposes of the present document, the terms and definitions given in EN 300 444 [12] and the following apply: 

attached to a line: PP that is attached to a line can send and receive calls on that line 

NOTE: A PP is 'attached to a line' if its associated bit is set in the 'Handset bitmap' in the 'Attached handsets' field 
of the 'Line Settings List' entry for that line. 

call status: part of the call information sent from FP to PP about the FP call state toward the peer party 

double call with in-band signalling (line): line on which second calls - incoming or outgoing - are handled using 
signalling transmitted or received "in-band" 

NOTE: The term typically applies to analog POTS legacy lines and the signalling is based on tones combined 
with interruptions in the loop DC circuit. 

FP-managed line selection: mode for an outgoing external call, in which the PP does not indicate the line to be used to 
the FP and the FP chooses the line where the call is placed 

GAP (PP, FP, device or equipment): PP, FP or any of them compliant with EN 300 444 [12] 

Headset PP (HPP): wireless headset telephone using the DECT air interface 

NOTE: A HPP usually has only one speaker and one microphone combined with a limited set of keys (e.g. call 
button, volume plus, and volume minus). Headsets provide the equivalent functionality of a PP with 
hands -free operation. 

late release: sending of a "CS idle" call status by the FP for a call that has been released a long time before in the 
network 

NOTE: See clause 7.4.3.10.3.1. 
line: logical channel, separately accessible from the external world through a dedicated external directory entry 
EXAMPLE: telephone number, URI, etc. 

NOTE: These lines may be of various types, for example: PSTN, VoIP or ISDN lines. 

multiple call line: line supporting several simultaneous (external) calls 

NOTE: An example of multiple call line is a VoIP line used with the SIP protocol. 

multiple-call mode: configuration mode of a multiple call line from a DECT system point of view, enabling several 
simultaneous incoming or outgoing calls on different PPs (i.e. this possibility is not disabled by configuration) 

new generation DECT: further development of the DECT standard introducing wideband speech, improved data 
services, new slot types and other technical enhancements 
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none: special line identifier value defined in clause 7.7.56 of EN 300 175-5 [5], used to indicate that the line id for the 
external call is not yet known 

NOTE: It is used for FP managed line selection (clauses 7.4.3.5.1 and 7.4.5.2.4) and, as a special case, for call 
intrusion (clause 7.4.3.8). 

NG-DECT Part 1 (PP, FP, device or equipment), also shortened as Part 1 (PP, FP, device or equipment): PP, FP 

or any of them compliant with TS 102 527-1 [21] 

NG-DECT Part 3 (PP, FP, device or equipment), also shortened as Part 3 (PP, FP, device or equipment): PP, FP 

or any of them compliant with the present document 

off-hook CLIP: ability of a network to send CLIP information for a waiting call (also known as "CLIP on call waiting" 
or "CLIP phase II") 

single-call mode: configuration mode of a multiple call line from a DECT system point of view, in which the 
possibility of making several fully parallel call is (temporarily) disabled 

NOTE: This mode may be useful for a user alone in the home. This mode does not prevent several simultaneous 
calls on the same PP. A line which is not "multiple call" (for instance a PSTN line only enabling double 
calls) is also said to be in "single call" mode. 

super-wideband speech: voice service with enhanced quality compared to ADPCM G.726 and allowing the 
transmission of a maximum vocal frequency of at least 14 kHz 

wideband speech: voice service with enhanced quality compared to ADPCM G.726 and allowing the transmission of a 
vocal frequency range of at least 150 Hz to 7 kHz, and fulfilling, at least, the audio performance requirements described 
in the Recommendation ITU-T P. 31 1 [i.6] 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

M mandatory to support (provision mandatory, process mandatory) 

optional to support (provision optional, process mandatory) 

1 out-of-scope (provision optional, process optional) not subject for testing 
C conditional to support (process mandatory) 

N/A not applicable (in the given context the specification makes it impossible to use this capability) 

Provision mandatory, process mandatory means that the indicated feature service or procedure is to be implemented as 
described in the present document, and may be subject to testing. 

Provision optional, process mandatory means that the indicated feature, service or procedure may be implemented, and 
if implemented, the feature, service or procedure is to be implemented as described in the present document, and may 
be subject to testing. 

NOTE: The used notation is based on the notation proposed in ISO/IEC 9646-7 [i. 15]. 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



AAC 


Advanced Audio Coding (MPEG) 


AAC-LD 


Advanced Audio Coding - Low Delay profile 


AC 


Authentication Code 


ADPCM 


Adaptive Differential Pulse Code Modulation 


AES 


Advanced Encryption Standard 


AI 


Air Interface 


ARI 


Access Rights Identity 


ARQ 


Automatic Repeat reQuest 


BCD 


Binary-Coded Decimal 


CC 


Call Control 


CF 


Call Forwarding 
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C F 


higher layer signalling Channel (fast) 


CFB 


Call Forwarding on Busy 


CFNA 


Call Forwarding on No Answer 


CFU 


Call Forwarding Unconditional 


CI 


Common Interface 


CISS 


Call Independent Supplementary Services 


CLIP 


Calling Line Identification Presentation 


CLIR 


Calling Line Identity Restriction 


CLMS 


ConnectionLess Message Service 


CLSS 


ConnectionLess Supplementary Service 


CN 


Carrier Number 


CNIP 


Calling Name Identification Presentation 


CRC 


Cyclic Redundancy Check 


cs 


Call Status 


c s 


higher layer signalling Channel (slow) 


DC 


Direct Current 


DCIBS 


Double Call with In-Band Signalling 


DCK 


Derived Cipher Key 


DECT 


Digital Enhanced Cordless Telecommunications 


DHCP 


Dynamic Host Configuration Protocol 


DLC 


Data Link Control 


DNS 


Domain Name System 


DSAA 


DECT Standard Authentication Algorithm 


DSAA2 


DECT Standard Authentication Algorithm #2 


DSC 


DECT Standard Cipher (algorithm) 


DSC2 


DECT Standard Cipher (algorithm) #2 


DTMF 


Dual Tone Multi-Frequency 


ECN 


Exchanged Connection Number (DLC/MAC layer) 


EMC 


Equipment Manufacturer's Code 


ER 


Error Resilient (MPEG) 


FEC 


Forward Error Correction 


FP 


Fixed Part 


FT 


Fixed radio Termination 


GAP 


Generic Access Profile 


GFSK 


Gaussian Frequency Shift Keying 


GMT 


Greenwich Mean Time 


HATS 


Head And Torso Simulator 


HPP 


Headset Portable Part 


HTTP 


HyperText Transfer Protocol 


IA 


Implementation Alternative 


IE 


Information Element 


% 


higher layer Information channel (uNprotected) 


IP 


Internet Protocol 


: PQ 


higher layer Information channel (protected) with single subfield format 


IPUI 


International Portable User Identity 


ISDN 


Integrated Services Digital Network 


IWU 


InterWorking Unit 


LA 


Location Area 


LAPC 


DLC layer C-plane protocol entity 


LCE 


Link Control Entity 


LD 


Low Delay (MPEG) 


LED 


Light-Emitting Diode 


LiA 


List Access 


LLME 


Lower Layer Management Entity 


MAC 


Medium Access Control 


MD 


Manufacturer Default 


ME 


Management Entity 


MM 


Mobility Management 


MMI 


Man Machine Interface 


MPEG 


Moving Picture Experts Group 


MWI 


Message Waiting Indication 
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NDT 


Network Delay Type 


NEM 


No Emission Mode 


NG 


New Generation 


NG-DECT 


New Generation DECT 


NTP 


Network Time Protocol 


NT 


identities information channel or one message in such channel 


NWK 


NetWorK 


P 


Public (environment) 


PABX 


Private Automatic Branch Exchange 


PAP 


Public Access Profile 


PARK 


Portable Access Rights Key 


PBX 


Private Branch Exchange 


PCM 


Pulse Code Modulation 


PHL 


PHysical Layer 


PLC 


Packet Loss Concealment 


POTS 


Plain Old Telephone Service 


PP 


Portable Part 


PSTN 


Public Switched Telephone Network 


PT 


Portable radio Termination 


R/B 


Residential/Business (environment) 


RFP 


Radio Fixed Part 


RFPI 


Radio Fixed Part Identity 


RSSI 


Radio Signal Strength Indicator 


S/T 


ISDN S/T Interface 


SAP 


Service Access Point 


SARI 


Secondary Access Rights Identity 


SDU 


Service Data Unit 


SIP 


Session Initiation Protocol 


SUOTA 


Software Update Over The Air 


TCLw 


weighted Telephone Coupling Loss 


TPUI 


Temporary Portable User Identity 


TRUP 


TRansparent Unprotected service 


U 


ISDN U-Interface 


UAK 


User Authentification Key 


UI 


User Identity 


UMT 


Universal Mean Time 


UNF 


Unprotected Framed service 


UPI 


Usewr Personal Identification 


UTF 


Unicode Transformation Format 


VoIP 


Voice over IP 


WB 


WideBand 


WMOPS 


Weighted Millions of Operations Per Second 


ZAP 


ability first to assign and then to re-program the account data held in the PP 



4 Description of Services 
4.1 Enhanced wideband speech 

The present document is defined as an extension of New Generation DECT; Part 1: wideband speech 
(TS 102 527-1 [21]). All devices compliant with the present document shall implement wideband (150 Hz to 7 kHz) 
audio with 16 kHz frequency sampling, and shall implement, at least, the speech coding format according to 
Recommendation ITU-T G.722 [17]. In addition to that, other wideband and super wideband audio codecs, providing 
even better audio quality, may be implemented. 

See TS 102 527-1 [21], clause 4.1 for description about wideband speech. 
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4.1 .1 Back-compatibility with GAP 

The present document is back compatible with Generic Access Profile (GAP) EN 300 444 [12]. All devices compliant 
with the present document shall implement ADPCM narrowband speech service according to 
Recommendation ITU-T G.726 [15], with automatic detection of the capabilities of the other peer. 

4.1 .2 Further enhancement in audio performance requirements 

The present document implements a further enhancement in acoustic wideband performance compared to 
TS 102 527-1 [21]: the more demanding audio specifications PP types 2b and 2c (see EN 300 175-8 [8]) are mandatory 
for all PPs compliant with the present document. With this extra requirement, the acoustic performance of the wideband 
speech service will be even better than the ITU standard for wideband audio, Recommendation ITU-T P. 31 1 [i.6]. 

See also TS 1 02 527- 1 [2 1 ] , clause 4.1.1. 

The present document implements also a further enhancement in acoustic performance for 3, 1 kHz narrowband service 
compared to GAP (EN 300 444 [12]) and TS 102 527-1 [21]: the more demanding audio specifications for PP types lc 
and Id (see EN 300 175-8 [8]) are mandatory for all PPs compliant with the present document. With this extra 
requirement, the acoustic performance of PPs compliant with the present document, when operating in 3,1 kHz 
narrowband service, will be even better than classic DECT/GAP specification. 

All audio types used by the present document are compatible with VoIP or long delay networks. 



4.2 Wideband speech scenarios 

See TS 102 527-1 [21], clause 4.2. 

4.3 Extended wideband speech services defined in the present 
document 

The following additional services are provided by the present document, compared to TS 102 527-1 [21]: 

• More demanding audio specifications for both; wideband and narrowband (see clause 4.1.2). 

• New simplified, "easy pairing" procedures. 

• New "no-emision" mode in FPs (switching down the dummy bearer when in idle mode). 

• Date and time synchronization. 

• CLIP and CNIP are now mandatory features. 

• Internal call and wideband Internal call (mandatory features). 

• CLIP and CNIP for Internal calls (mandatory features). 

• Generic Event notification mechanism, providing support for: 

Message waiting indication. 
Missed call notification. 

• List access service. 

• Handling of multiple calls between the same PP and the RFP. 

• CLIP and CNIP on call waiting. 

• CLIP and CNIP on call transfer. 

• Call deflection. 
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• Call identification and Line identification features. 

• CLIR feature. 

• Multiple calls and multiple lines features. 

• Mutualised parallel calls. 

• New system settings and line settings. 

• Informative annexes with more examples of flowcharts, including system settings, multiple calls and parallel 
calls. 

The new extended services, take in to account the additional scenarios possible in DECT systems connected to the 
network via VoIP interfaces. 

5 Service and feature definitions 

5.1 New Generation DECT Speech Services 

For the purposes of the present document, the definitions of TS 102 527-1 [21], clause 5.1 shall apply. 

5.2 Network (NWK) features 

For the purposes of the present document, all definitions of TS 102 527-1 [21], clause 5.2 and EN 300 444 [12], 
clause 4.1, plus the following shall apply: 

Missed call notification [NG1.N.3]: ability to inform a user that a call has been missed. 

Voice message waiting notification [NG1.N.4]: ability to inform a user that a voice message has been left in the voice 
mailbox to which the user has access. 

Date and time synchronization [NG1.N.5]: ability to synchronize the date and time on the DECT system. From FP to 
all registered PP or from one registered PP to the FP. 

Parallel calls [NG1.N.6]: ability to handle in the DECT system two or more simultaneous calls originated or 
terminated in the same PP. 

Common parallel call procedures (external or internal) [NG1.N.7]: set of common procedures for handling PSTN 
double calls, SIP multiple calls on a single line, as well as parallel call situations occurring in a multiple line DECT 
system. 

Call transfer (internal or external) [NG1.N.8]: ability to create a new call while already involved in a call and 
connect the remote party to it (kind of parallel calls). 

3-party conference call (internal or external) [NG1.N.9]: ability to connect the local party and the two remote parties 
of two parallels calls into a single conference (kind of parallel calls). 

Intrusion call [NG1.N.10]: ability for a PP not participating to an already established call to connect to it (kind of 
parallel calls). Intrusion call is also known as "barging in". 

Call deflection [NG1.N.11]: ability to redirect an incoming call during the call presentation to another user. 

Line identification [NG1.N.12]: ability to exchange between the PP and FP a line identifier for external calls. 

Call identification [NG1.N.13]: ability to exchange between the PP and FP a call identifier assigned by the FP at call 
setup and call statuses from FP to PP. 

Multiple lines [NG1.N.14]: ability for a DECT System to handle several external lines. 

Multiple calls [NG1.N.15]: ability for a DECT System to handle a line supporting several simultaneous external calls. 
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List access service [NG1.N.16]: ability to store information on the DECT system in a set of lists on the FP and manage 
these lists from the PP. 

Calling Line Identity Restriction (CLIR) [NG1.N.17]: ability for the user to hide the identity of his line (i.e. Calling 
Line Identity Presentation) to the called party. 

Call forwarding [NG1.N.18]: ability to request to the network a redirection of incoming calls. 

DTMF handling [NG1.N.19]: ability to handle DTMF signalling and generation. 

Tones provision [NG1.N.20]: ability to support complete call progress tones generation. 

Headset management [NG1.N.21]: ability to handle calls with a headset PP in a DECT system. 

Handling of lines where second calls are signalled in-band [NG1.N.22]: ability to handle second calls on PSTN lines 
or lines following similar rules. 

5.3 Data Link Control (DLC) service definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [21], clause 5.3 and EN 300 444 [12], 
clause 5.1 shall apply. 

5.4 Medium Access Control (MAC) service definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [21], clause 5.4 and EN 300 444 [12], 
clause 5.2, plus the following shall apply: 

"no emission" mode [NG1.M.5]: ability to deactivate all radio transmissions in a DECT FP when it does not handle 
any call. Power-down is negotiated and an algorithm is provided, that guarantees a short resynchronization time, if an 
RF-connection is required by any of the peers. 

5.5 Physical Layer (PHL) service definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [21], clause 5.5 shall apply. 

5.6 Speech coding and audio feature definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [21], clause 5.6 shall apply. 

5.7 Application features 

For the purposes of the present document, all definitions of EN 300 444 [12], clause 4.3 plus the following shall apply: 

Easy PIN code registration [NG1.A.1]: ability to invite the user to register a PP that is not registered to a FP. The 
access rights procedure is triggered by PIN entering. 

Easy pairing registration [NG1.A.2]: ability to register a PP that is not registered to a FP by pressing a physical or 
logical button on the PP and on the FP. 

Handset locator [NG1.A.3]: ability to locate physically handsets (have them ring) by pressing a physical or logical 
button on the FP. 
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6 Inter-operability requirements 

6.1 General 

The tables listed in this clause define the status of all protocol elements (i.e. features, services, and procedures) which 
can be: mandatory, optional, conditional under the provision of another protocol element, outside the scope of the 
present document, or not applicable. The status is identified by the status column designations defined in clause 3.2 and 
is described separately for FT and PT. In the case of FT, the status can be different for products intended for the 
Residential/Business (R/B) market or for the Public market segment. 

All optional elements shall be process mandatory according to the procedures described in the present document. 

Protocol elements defined as mandatory, optional or conditional in this clause are further defined in the referenced 
DECT specification, or, if needed, in clause 7 of the present document. 

New Generation DECT wideband speech is defined as a back compatible enhancement of EN 300 444 [12] (Generic 
Access Profile (GAP)). All procedures not specific of the New Generation DECT, are referenced to their original 
description in EN 300 444 [12] (GAP). 

The requirements of EN 301 406 [11] and EN 300 176-2 [10] shall be met by all equipment conforming to the present 
document. 

6.2 New Generation DECT Speech Services support status 

The following end-user speech services are defined by the present document: 



Table 1 : Speech services status 



Feature supported 




Status 


Item no. 


Name of Service 


Reference 


PT 


FT 


R/B 


P 


NG1.1 


Narrow band ADPCM G.726 32 kbit/s voice service 


5.1 [211 


M 


M 


M 


NG1.2 


Narrow band PCM G.71 1 64 kbit/s voice service 


5.1 [211 


O 


O 


O 


NG1.3 


Wideband G.722 64 kbit/s voice service 


5.1 [21] 


M 


M 


M 


NG1.4 


Wideband G.729.1 32 kbit/s voice service 


5.1 [21] 


O 


O 


O 


NG1.5 


MPEG-4 ER AAC-LD super wideband 64 kbit/s voice service 


5.1 [211 


O 


O 


O 


NG1.6 


MPEG-4 ER AAC-LD wideband 32 kbit/s voice service 


5.1 [21] 





O 


O 



6.3 Services to DECT feature implementation mappings 

"New Generation DECT; part 3: Extended wideband speech services" end user services shall be implemented using the 
DECT features and implementation alternatives defined in table 2. 



Table 2: Speech services to DECT features implementation mappings 



Service/DECT Feature mapping 




Status 


Service 


IA 


DECT feature/service 


Reference 


PT 


FT 


R/B 


P 


NG1.1 Narrow band ADPCM 
G.726 32 kbit/s voice service 


I 




5.1 [21] 


M 


M 


M 


NG1 .P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 


NG1.P.2 Physical Packet P32 


5.5 [21] 


M 


M 


M 


NG1.M.1 iNjninimum delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 


GAP.M.4 Basic Connections 


5.2 [121 


M 


M 


M 


NG1 .M.4 Advanced Connections 


5.4 [21] 


C201 


C201 


C201 
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Service/DECT Feature mapping 




Status 


Service 


IA 


DECT feature/service 


Reference 


PT 


FT 


R/B 


P 






NG1.D.1 DLC Service LU1 TRUP Class 
0/min delay 


5.3 [21] 


M 


M 


M 






NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1.SC.1 

Recommendation ITU-T G.726 [15] 
32 kbit/s ADPCM codec 


5.6 [21] 


M 


M 


M 






NG1.SC.10 PP Audio type 1a (classic 
GAP handset) 


5.6 [21] 


I 


N/A 


N/A 






NG1.SC.11 PP Audio type 1b 
(improved GAP handset) 


5.6 [21] 


I 


N/A 


N/A 






NG1.SC.12 PP Audio type 1c (HATS 
3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1.SC.13 PP Audio type 1d (HATS 
3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1 .SC.1 7 PP Audio type 3a (HATS 
3,1 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.18 PP Audio type 3b (HATS 
3,1 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.24 PP echo canceller for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.25 PP echo suppressor for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.27 FP Audio type 3 (VoIP 
3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC. 32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC. 33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control for 

CD 

rr 


5.6 [21] 


N/A 








Nui.z Narrow Dana koivi 


i 




0.1 L<iij 


r\ 
\J 








G.711 64 kbit/s voice service 




NG1.P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 






NG1.P.3 Physical Packet P64 


5.5 [21] 


M 


M 


M 






NG1.M.1 lN_minimum delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 .M.4 Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1.D.1 DLC Service LU1 TRUP Class 
O/min delay 


5.3 [21] 


M 


M 


M 






NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1.SC.2 

Recommendation ITU-T G.711 [16] 
64 kbit/s PCM codec 


5.6 [21] 


M 


M 


M 






NG1.SC.8 Detection of Fax/modem 
tone 


5.6 [21] 















NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1.SC.10 PP Audio type 1a (classic 
GAP handset) 


5.6 [21] 


I 


N/A 


N/A 






NG1.SC.11 PP Audio type 1b 
(improved GAP handset) 


5.6 [21] 


I 


N/A 


N/A 






NG1.SC.12 PP Audio type 1c (HATS 
3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1.SC.13 PP Audio type 1d (HATS 
3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1 .SC.1 7 PP Audio type 3a (HATS 
3,1 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.18 PP Audio type 3b (HATS 
3,1 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 



ETSI 



24 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



Service/DECT Feature mapping 




Status 


Service 


IA 


DECT feature/service 


Reference 


PT 


FT 


R/B 


P 






NG1 .SC.23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.24 PP echo canceller for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.25 PP echo suppressor for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.27 FP Audio type 3 (VoIP 
3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control for 

CD 

rr 


5.6 [21] 


N/A 








Nui.£ Narrow Dana roivi 


ii 
ii 




C -i TOi 1 

o.i L<iij 


r\ 
u 





o I 


G.711 64 kbit/s voice service 




NG1 .P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 






NG1.P.4 Physical Packet P67 


5.5 [21] 


M 


M 


M 






NG1.M.3 lpQ_error_detection symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 .M.4 Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1.D.1 DLC Service LU1 TRUP Class 
0/min_delay 


5.3 [21] 


M 


M 


M 






NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1.SC.2 

Recommendation ITU-T G.711 [16] 
64 kbit/s PCM codec 


5.6 [21] 


M 


M 


M 






NG1.SC.8 Detection of Fax/modem 
tone 


5.6 [21] 















NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1.SC.10 PP Audio type 1a (classic 
GAP handset) 


5.6 [21] 


I 


N/A 


N/A 






NG1.SC.11 PP Audio type 1b 
(improved GAP handset) 


5.6 [21] 


I 


N/A 


N/A 






NG1.SC.12 PP Audio type 1c (HATS 
3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1.SC.13 PP Audio type 1d (HATS 
3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1 .SC.1 7 PP Audio type 3a (HATS 
3,1 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.18 PP Audio type 3b (HATS 
3,1 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.24 PP echo canceller for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.25 PP echo suppressor for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.26 FP Audio type 2 (analog 

|— \ — T— ft | f*\ J III \ 

PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.27 FP Audio type 3 (VoIP 
3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 


Service 


IA 


DECT feature/service 


Reference 


PT 


FT 


D /D 
K/b 




Nui.^ Narrow Dana roivi 


in 
in 




0.1 l^ij 


r\ 
\J 








G.711 64 kbit/s voice service 




NG1.P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 






NG1.P.5 Physical Packet P80 


5.5 [21] 


M 


M 


M 






NG1.M.2 lN_normal_delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 .M.4 Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1 .D.3 DLC service LU7 64 kbit/s 
protected bearer service 


5.3 [21] 


M 


M 


M 






NG1.D.6 DLC frame FU7 


5.3 [21] 


M 


M 


M 






NG1.SC.2 

Recommendation ITU-T G.711 [16] 
64 kbit/s PCM codec 


5.6 [21] 


M 


M 


M 






NG1.SC.8 Detection of Fax/modem 
tone 


5.6 [21] 















NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1.SC.10 PP Audio type 1a (classic 
GAP handset) 


5.6 [21] 


I 


N/A 


N/A 






NG1.SC.11 PP Audio type 1b 
(improved GAP handset) 


5.6 [21] 


I 


N/A 


N/A 






NG1.SC.12 PP Audio type 1c (HATS 
3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1.SC.13 PP Audio type 1d (HATS 
3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 






NG1 .SC.1 7 PP Audio type 3a (HATS 
3,1 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.18 PP Audio type 3b (HATS 
3,1 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.24 PP echo canceller for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.25 PP echo suppressor for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 






NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.27 FP Audio type 3 (VoIP 
3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 






NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 


Service 


IA 


DECT feature/service 


Reference 


PT 


FT 


D/D 

ri/b 


□ 
r 


Kir* 4 n lA#i*J«u*, M/ J "7 ly-u-T TOO 


i 




0.1 l^ij 


M 


M 


M 


64 kbit/s voice service 




NG1.P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 






NG1.P.3 Physical Packet P64 


5.5 [21] 


M 


M 


M 






NG1.M.1 ^minimum delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 .M.4 Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1.D.1 DLC Service LU1 TRUP Class 
0/min_delay 


5.3 [21] 


M 


M 


M 






NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1.SC.3 

Recommendation ITU-T G.722 [17] 
64 kbit/s 7 kHz wideband codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.7 Packet loss Concealment 
(PLC) for 

Recommendation ITU-T G.722 [17] 


5.6 [21] 















NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1.SC.14 PP Audio type 2a 
(Recommendation ITU-T P. 311 [i.6] 
7 kHz handset) 


5.6 [21] 


I 


N/A 


N/A 






NG1 .SC.15 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SC.1 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SC.1 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.29 FP Audio type 5 (VoIP 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.30 NG1 .SC. 24 PP echo 
canceller for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1.SC.31 NG1.SC.24 PP echo 
suppressor for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 


Service 


IA 


DECT feature/service 


Reference 


PT 


FT 


D ID 
K/b 


□ 

r 


iNui.o wiaeDana / khz u./^ 


ii 
ii 




0.1 l^ij 


r\ 
\J 








64 kbit/s voice service 




NG1.P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 






NG1.P.3 Physical Packet P67 


5.5 [21] 


M 


M 


M 






NG1.M.3 lpQ_error_detection symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 .M.4 Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1.D.1 DLC Service LU1 TRUP Class 
0/min_delay 


5.3 [21] 


M 


M 


M 






NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1.SC.3 

Recommendation ITU-T G.722 [17] 
64 kbit/s 7 kHz wideband codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.7 Packet loss Concealment 
(PLC) for 

Recommendation ITU-T G.722 [17] 


5.6 [21] 















NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1.SC.14 PP Audio type 2a 
(Recommendation ITU-T P. 311 [i.6] 
7 kHz handset) 


5.6 [21] 


I 


N/A 


N/A 






NG1 .SC.15 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SC.1 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SC.1 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.29 FP Audio type 5 (VoIP 
wideband 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.30 NG1 .SC. 24 PP echo 
canceller for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1.SC.31 NG1.SC.24 PP echo 
suppressor for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 


Service 


IA 


DECT feature/service 


Reference 


PT 


FT 


R/B 


P 


NG1 .4 Wideband 7 kHz G.729.1 


1 




5.1 [21] 





O 


o 


o£ kdii/s voiC6 service 




NG1.P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 






NG1.P.3 Physical Packet P32 


5.5 [21] 


M 


M 


M 






NG1.M.2 l N _normal_delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 .M.4 Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1 .D.4 DLC service LU12 (UNF) 
Class 


5.3 [21] 


M 


M 


M 






NG1.D.7 DLC frame FU 12 with 
adaptation for codec G.729.1 


5.3 [21] 


M 


M 


M 






NG1.SC.4 

Recommendation ITU-T G.729.1 [18] 
32 kbit/s 7 kHz wideband codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1.SC.14 PP Audio type 2a 
(Recommendation ITU-T P. 311 [i.6] 
7 kHz handset) 


5.6 [21] 


I 


N/A 


N/A 






NG1 .SC.15 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SC.1 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SC.1 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.29 FP Audio type 5 (VoIP 
wideband 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC. 30 NG1 .SC. 24 PP echo 
canceller for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1.SC.31 NG1.SC.24 PP echo 
suppressor for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC. 34 Adaptive volume control 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 


Service 


IA 


DECT feature/service 


Reference 


PT 


FT 


R/B 


P 


NG1.5 Superwideband 14 kHz 


I 




5.1 [21] 





r\ 
U 




MPFR.d FR AAf.l n fid khit/e 




Niji.r.i d. level broi\ rnoouiation 


c c roi l 
0.0 [d.\\ 


IVI 


M 


M 


voice service 




NG1.P.3 Physical Packet P64 


5.5 [21] 


M 


M 


M 






NG1.M.2 lN_normal_delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 .M.4 Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1 .D.2 DLC Service LU1 Class 


5.4 [21] 


M 


M 


M 






NG1 .D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1 .SC.5 MPEG4 AAC-LD 64 kbit/s 
14 kHz superwideband codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1.SC.21 PP Audio type 5a 
(Superwideband 14 KHz handset) 


5.6 [21] 


M 


N/A 


N/A 






NG1.SC.22 PP Audio type 5b 
(Superwideband 14 KHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC. 29 FP Audio type 5 (VoIP 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC. 32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC. 33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 


O 


O 






NG1 .SC. 34 Adaptive volume control for 
pp 

rr 


0.0 [^1J 


M/A 

N/A 


U 


U 


NG1.5 Superwideband 14 kHz 


II 




5.1 [21] 





KJ 




MPFR.d FR AAP-I n fid khit/c 




D -\ O Irtw^l /"'POL*' r*-»^j-li 

Nbi .r.\ d. level ijroi\ moauiation 


0.0 [d\ \ 


IVI 


M 


M 


voice service 




NG1.P.3 Physical Packet P67 


5.5 [21] 


M 


M 


M 






NG1.M.3 lpQ_error_detection symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 .M.4 Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1 .D.2 DLC service LU1 Class 


5.3 [21] 


M 


M 


M 






NG1 .D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1 .SC.5 MPEG4 AAC-LD 64 kbit/s 
14 kHz superwideband codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1.SC.21 PP Audio type 5a 
(Superwideband 14 KHz handset) 


5.6 [21] 


M 


N/A 


N/A 






NG1.SC.22 PP Audio type 5b 
(Superwideband 14 KHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.28 FP Audio type 4 (ISDN 

'ii i \ 

wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.29 FP Audio type 5 (VoIP 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC. 34 Adaptive volume control for 
FP 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 


Service 


IA 


DECT feature/service 


Reference 


PT 


FT 


R/B 


P 


NG1 .6 Wideband 11 kHz 


I 




5.1 [21] 





r\ 
U 


r\ 
\J 






Niji.r.i d. level broi\ moouiation 




IVI 


M 


M 


voice service 




NG1.P.3 Physical Packet P32 


5.5 [21] 


M 


M 


M 






NG1.M.2 lN_normal_delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 






NG1 .M.4 Advanced Connections 


5.4 [21] 


M 


M 


M 






NG1 .D.2 DLC service LU1 Class 


5.4 [21] 


M 


M 


M 






NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 






NG1 .SC.6 MPEG4 AAC-LD 32 kbit/s 
1 1 kHz wideband codec 


5.6 [21] 


M 


M 


M 






NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 






NG1.SC.14 PP Audio type 2a 
(Recommendation ITU-T P. 311 [i.6] 
7 kHz handset) 


5.6 [21] 


I 


N/A 


N/A 






NG1 .SC.15 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SC.1 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 






NG1 .SC.1 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 






NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.29 FP Audio type 5 (VoIP 
wideband) 


5.6 [21] 


N/A 


C708 


C708 






NG1 .SC.30 NG1 .SC.24 PP echo 
canceller for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1.SC.31 NG1 .SC.24 PP echo 
suppressor for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 






NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 






NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 












NG1 .SC.34 Adaptive volume control 


5.6 [21] 


N/A 








IA = Implementation Alternative: 

C201 : Advanced connections for Service NG1 .1 shall only be used in the case of multiple connections 

between the same PT-FT pair. The support of this case is optional. 
C702: At least one should be provided. C703:At least one should be provided.). 
C706: At least one should be provided. 

C707: IF feature NG1 .SC.23 (FP type 1b) OR NG1 .SC.27 (FP type 3) THEN ELSE I. Either NG1 .SC.24 or 

NG1 .SC. 25 may be provided, but not both at the same time. 
C708: At least one should be provided. 

C709: IF feature NG1 .SC.28 (FP type 4) OR NG1 .SC.29 (FP type 5) THEN ELSE I. Either NG1 .SC.30 or 
NG1 .SC. 31 may be provided, but not both at the same time. 
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6.4 NWK features 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following Network 
layer features: 



Table 3: NWK features status 



Feature supported 




Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


R/B 


p 


NG1.N.1 


Codec Negotiation 


5.2 [21] 


M 


M 


M 


NG1.N.2 


Codec Switching 


5.2 [21] 

L J 


M 


M 


M 


NG1.N.3 


Missed call notification 


5.2 


M 


M 


M 


NG1.N.4 


Voice message waiting notification 


5.2 


M 


M 


M 


NG1.N.5 


Date and Time synchronization 


5.2 


M 


M 


M 


NG1.N.6 


Parallel calls 


5.2 


M 


M, 
note 7 





NG1.N.7 


Common parallel call procedures (external or internal) 


5.2 


M 


M, 
note 7 





NG1.N.8 


Call transfer (external or internal) 


5.2 


M 


M 





NG1.N.9 


3-party conference with established external and/or internal 
calls 


5.2 





0, 
note 6 


0, 
note 6 


NG1.N.10 


Intrusion call 


5.2 





0, 
note 6 


0, 
note 6 


NG1.N.11 


Call deflection (external or internal) 


5.2 





0, 
note 6 


0, 
note 6 


NG1.N.12 


Line identification 


5.2 


M 


M 


M 


NG1.N.13 


Call identification 


5.2 


M 


M 


M 


NG1.N.14 


Multiple Lines 


5.2 


M 








NG1.N.15 


Multiple calls 


5.2 


M 


M 





NG1.N.16 


List access service 


5.2 


M 


M 





NG1.N.17 


Calling line identity restriction 


5.2 











NG1.N.18 


Call forwarding (external calls) 


5.2 


M 


M 


I 


NG1.N.19 


DTMF handling 


5.2 


M 


M 





NG1.N.20 


Tones provision 


5.2 


M 


M 





NG1.N.21 


Headset management 


5.2 


C301 


M 





NG1.N.22 


Handling of lines where second calls are signalled in-band 


5.2 


M 


0, 
note 7 





GAP.N.1 


Outgoing call 


4.1 [12] 


M 


M 


M 


GAP.N.2 


Off hook 


4.1 [12] 


M 


M 


M 


GAP.N.3 


On hook (full release) 


4.1 [12] 


M 


M 


M 


GAP.N.4 


Dialled digits (basic) 


4.1 [12] 


M 


M 


M 


GAP.N.5 


Register recall (see notes 4 and 5) 


4.1 [12] 


M 








GAP.N.6 


Go to DTMF signalling (defined tone length) (see note 1) 


4.1 [12] 


M 





M 


GAP.N.7 


Pause (dialling pause) (see note 3) 


4.1 [12] 


M 








GAP.N.8 


Incoming call 


4.1 [12] 


M 


M 


M 


GAP.N.9 


Authentication of PP 


4.1 [12] 


M 


M 


M 


GAP.N10 


Authentication of user (see note 2) 


4.1 [12] 


M 








GAP.N.1 1 


Location registration 


4.1 [12] 


M 





M 


GAP.N.12 


On air key allocation (see note 2) 


4.1 [12] 


M 


M 





GAP.N.13 


Identification of PP 


4.1 [12] 


M 








GAP.N.14 


Service class indication/assignment 


4.1 [12] 


M 





M 


GAP.N.15 


Alerting 


4.1 [12] 


M 


M 


M 


GAP.N.16 


ZAP (see note 2) 


4.1 [12] 


M 








GAP.N.17 


Encryption activation FT initiated 


4.1 [12] 


M 


M 


M 


GAP.N.18 


Subscription registration procedure on-air 


4.1 [12] 


M 


M 


M 


GAP.N.19 


Link control 


4.1 [12] 


M 


M 


M 


GAP.N.20 


Terminate access rights FT initiated (see note 2) 


4.1 [12] 


M 


M 





GAP.N.21 


Partial release 


4.1 [12] 











GAP.N.22 


Go to DTMF (infinite tone length) 


4.1 [12] 











GAP.N.23 


Go to Pulse 


4.1 [12] 











GAP.N.24 


Signalling of display characters 


4.1 [12] 











GAP.N.25 


Display control characters 


4.1 [12] 
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Feature supported 





Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


R/B 


p 


GAP N ?fi 


Ai ithpntipatinn nf FT 

rAU L 1 I C I 1 11 Ud 11 U 1 I Ul 1 1 


4.1 [12] 




n 


n 


GAP N ?7 


Fnpn/ntinn aptivatinn PT initiatprl 

l_l IUI y [J LIUI 1 dl^UVdUUII 1 1 IllllldlCU 


4.1 [12] 


o 


o 


o 


GAP N 28 


Fnprvntinn Hpartiv/Ption FT initiptprl 


4.1 [12] 


o 








GAP.N.29 


Encryption deactivation PT initiated 


4.1 [12] 











GAP.N.30 


Calling Line Identification Presentation (CLIP) 


4.1 [12] 


M 


M 


M 


GAP.N.31 


Internal call 


4.1 [12] 


M 


M 


M 


GAP.N.32 


Service call 


4.1 [12] 











GAP.N.33 


Enhanced U- plane connection 


4.1 [12] 











GAP.N.34 


Calling Name Identification Presentation (CNIP) 


4.1 [12] 


M 


M 


M 


GAP.N.35 


Enhanced security 


4.1 [12] 


M 


M 


M 


GAP.N.36 


AES/DSAA2 authentication 


4.1 [12] 


C302 


C302 


C302 



C301 : IF the PT is a headset PP THEN M ELSE I. 
C302: IF MAC service GAP.M.17 THEN M ELSE O. 



NOTE 1 : The PT is only required to be able to send the «MULTI-KEYPAD» information element containing the 

DECT standard 8-bit character (EN 300 175-5 [5], annex D) codings "Go to DTMF", defined tone length 

and the FT is required to be able to understand it in the public environment. 
NOTE 2: This feature is required to be supported in the PT to guarantee the same level of security among all the 

handsets that operates in a system. The invocation of the feature is however optional to the operator. 
NOTE 3: The PT is required to be able to send the «MULTI-KEYPAD» information element containing the DECT 

standard 8-bit character (EN 300 175-5 [5], annex D) codings "Dialling Pause". This guarantees 

automatic access to secondary or alternative networks. 
NOTE 4: This feature uses keypad code 15 hex. 

NOTE 5: The FT is not mandated to receive and understand the register recall DECT character. However, if a FT 
supports it there may be no corresponding action that the FT can take with the local network as a result of 
this function. 

NOTE 6: If the feature is not supported on FT side, the FT shall however implement the "sending negative 
acknowledgement" procedure (see clause 7.4.3.4). 

NOTE 7: All procedures of NG1 .N.6 and NG1 .N.7 shall apply to all FTs and for all line types (full parallel call 

compliant lines and DCIBS lines). For DCIBS lines, the FT shall implement in addition NG1 .N.22 feature, 
which describes some amendments to NG1 .N.6 and NG1 .N.7 for such lines. A given FT shall be 

designed to handle both line types, or only one of them. 



6.5 Data Link Control (DLC) services 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following DLC 
services: 

Table 4: DLC services status 



Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 


R/B 


P 


NG1.D.1 


LU1 Transparent Unprotected service (TRUP) Class 
/minimum_delay 


5.3 [21] 


M 


M 


M 


NG1.D.2 


LU1 Transparent Unprotected service (TRUP) Class 


5.3 [21] 


C401 


C401 


C401 


NG1.D.3 


LU7 64 kbit/s protected bearer service 


5.3 [21] 


C401 


C401 


C401 


NG1.D.4 


LU 12 Unprotected Framed service (UNF) Class 


5.3 [21] 


C401 


C401 


C401 


NG1.D.5 


FU1 DLC frame 


5.3 [21] 


M 


M 


M 


NG1.D.6 


FU7 DLC frame 


5.3 [21] 


C401 


C401 


C401 


NG1.D.7 


FU12 DLC frame with adaptation for codec G. 729.1 


5.3 [21] 


C401 


C401 


C401 


GAP.D.1 


LAPC class A service and Lc 


5.1 [121 


M 


M 


M 


GAP.D.2 


Cs channel fragmentation and recombination 


5.1 [12] 


M 


M 


M 


GAP.D.3 


Broadcast Lb service 


5.1 [12] 


M 


M 


M 


GAP.D.4 


Intra-cell voluntary connection handover 


5.1 [12] 


M 


C402 


C402 


GAP.D.5 


Intercell voluntary connection handover (see note) 


5.1 [121 


M 


O 


O 


GAP.D.6 


Encryption activation 


5.1 [12] 


M 


C404 


M 


GAP.D.9 


Encryption deactivation 


5.1 [12] 


C403 


C403 


C403 
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Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 


R/B | P 


C401: 
C402: 
C403: 
C404: 


Status defined by clause 6.3, table 2. 

IF service GAP.M.9 THEN ELSE M. 

IF feature GAP.N.29 OR GAP.N.28 THEN M ELSE I. 

IF feature GAP. N. 17 OR GAP.N.27 THEN M ELSE I. 








NOTE: 


The PT is required to be able to support handover between RFPs. The invocation of the feature is 
however optional to the operator. 



6.6 Medium Access Control (MAC) services 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following MAC layer 
services: 

Table 5: MAC services status 



Service supported 





Status 


Item no. 


Name of service 


Reference 


PT 


FT 


R/B 


P 


NG1.M.1 


lN_minimum delay symmetric MAC service type 


5.4 [21] 


M 


M 


M 


NG1.M.2 


In normal delay symmetric MAC service type 


5.4 [21] 


C501 


C501 


C501 


NG1.M.3 


lpQ_error_detection symmetric MAC service type 


5.4 [21] 


C501 


C501 


C501 


NG1.M.4 


Advanced connections 


5.4 [21] 


M 


M 


M 


NG1.M.5 


"no emission" mode 


5.4 











GAP.M.1 


General 


5.2 [12] 


M 


M 


M 


GAP.M.2 


Continuous broadcast 


5.2 [12] 


M 


M 


M 


GAP.M.3 


Paging broadcast 


5.2 [12] 


M 


M 


M 


GAP.M.4 


Basic connections 


5.2 [12] 


M 


M 


M 


GAP.M.5 


Cs higher layer signalling 


5.2 [12] 


M 


M 


M 


GAP.M.6 


Quality control 


5.2 [12] 


M 


M 


M 


GAP.M.7 


Encryption activation 


5.2 [12] 


M 


M 


M 


GAP.M.8 


Extended frequency allocation (see note 1 ) 


5.2 [12] 


M 








GAP.M.9 


Bearer Handover, intra-cell 


5.2 [12] 


M 


C502 


C502 


GAP.M.10 


Bearer Handover, inter-cell 


5.2 [12] 


M 








GAP.M.1 1 


Connection Handover, intra-cell 


5.2 [12] 


M 


C503 


C503 


GAP.M.12 


Connection Handover, inter-cell 


5.2 [12] 


M 








GAP.M.13 


SARI support 


5.2 [12] 


M 








GAP.M.14 


Encryption deactivation 


5.2 [12] 


C504 


C504 


C504 


GAP.M.15 


Re-keying 


5.2 [12] 


C505 


C505 


C505 


GAP.M.16 


Early encryption 


5.2 [12] 


C506 


C506 


C506 


GAP.M.17 


AES/DSC2 encryption (see note 2) 


5.2 [12] 












C501 : Status defined by clause 6.3, table 2. 
C502: IF service GAP.M.1 1 THEN O ELSE M. 
C503: IF service GAP.M.9 THEN O ELSE M. 
C504: IF feature GAP.N.29 OR N.28 THEN M ELSE I. 

C505: IF feature GAP.N.35 and NWK layer procedure "Re-keying during a call" are implemented THEN M ELSE 
O. 

C506: IF feature GAP.N.35 and NWK layer procedure "Early encryption" are implemented THEN M ELSE O. 
NOTE 1 : Handsets not supporting these extra frequencies need only adapt scanning to allow continued use of the 
standard DECT frequencies. 

NOTE 2: IF implemented THEN NWK feature GAP.N.36 shall be implemented. 
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6.7 Physical layer (PHL) services 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following Physical layer 
(PHL) services: 



Table 6: PHL services status 



Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 


R/B 


P 


NG1.P.1 


2 level GFSK modulation 


5.5 [21] 


M 


M 


M 


NG1.P.2 


Physical Packet P32 


5.5 [21] 


M 


M 


M 


NG1.P.3 


Physical Packet P64 


5.5 [21] 


M 


M 


M 


NG1.P.4 


Physical Packet P67 


5.5 [21] 











NG1.P.5 


Physical Packet P80 


5.5 [21] 












The requirements of EN 300 444 [12], clause 11 also apply. 

6.8 Speech coding and audio features 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following Speech 
coding and audio related features: 



Table 7: Speech Coding and audio features 



Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 


R/B 


P 


NG1.SC.1 


G.726 32 kbit/s ADPCM codec 


5.6 [21] 


M 


M 


M 


NG1.SC.2 


G.71 1 64 kbit/s PCM codec 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.3 


G.722 64 kbit/s 7 kHz wideband codec 


5.6 [21] 


M 


M 


M 


NG1.SC.4 


G. 729.1 32 kbit/s 7 kHz wideband codec 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.5 


MPEG4 AAC-LD 64 kbit/s 14 kHz superwideband codec 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.6 


MPEG4 AAC-LD 32 kbit/s 1 1 kHz wideband codec 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.7 


Packet Loss Concealment (PLC) for G.722 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.8 


Detection of Fax/modem tone 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.9 


Codec selection and switching 


5.6 [21] 


M 


M 


M 


NG1.SC.10 


PP Audio profile type 1a (classic GAP handset) 


5.6 [21] 


I 


N/A 


N/A 


NG1.SC.11 


PP Audio profile type 1b (improved GAP handset) 


5.6 [21] 


I 


N/A 


N/A 


NG1.SC.12 


PP Audio profile type 1c (HATS 3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1.SC.13 


PP Audio profile type 1d (HATS 3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1.SC.14 


PP Audio profile type 2a (Recommendation ITU-T P.31 1 [i.6] 
7 kHz handset) 


5.6 [21] 


I 


N/A 


N/A 


NG1.SC.15 


PP Audio profile type 2b (HATS 7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1.SC.16 


PP Audio profile type 2c (HATS 7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1.SC.17 


PP Audio profile type 3a (HATS 3,1 kHz handsfree) 


5.6 [21] 


O 


N/A 


N/A 


NG1.SC.18 


PP Audio profile type 3b (HATS 3,1 kHz improved handsfree) 


5.6 [21] 


O 


N/A 


N/A 


NG1.SC.19 


PP Audio profile type 4a (HATS 7 kHz handsfree) 


5.6 [21] 


O 


N/A 


N/A 


NG1.SC.20 


PP Audio profile type 4b (HATS 7 kHz improved handsfree) 


5.6 [21] 


O 


N/A 


N/A 


NG1.SC.21 


PP Audio profile type 5a superwideband (14 kHz) handset 


5.6 [21] 


C704 


N/A 


N/A 


NG1.SC.22 


PP Audio profile type 5b superwideband (14 kHz) handsfree 


5.6 [21] 


C705 


N/A 


N/A 


NG1.SC.23 


FP Audio type 1 b (new ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1.SC.24 


PP echo canceller for FP, narrowband 


5.6 [21] 


N/A 


C707 


C707 


NG1.SC.25 


PP echo suppressor for FP, narrowband 


5.6 [21] 


N/A 


C707 


C707 


NG1.SC.26 


FP Audio type 2 (analog PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1.SC.27 


FP Audio type 3 (VoIP 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1.SC.28 


FP Audio type 4 (ISDN wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1.SC.29 


FP Audio type 5 (VoIP wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1.SC.30 


PP echo canceller for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 
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Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 


R/B 


P 


NG1.SC.31 


PP echo suppressor for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 


NG1.SC.32 


FP Audio type 6a (internal call) 


5.6 [21] 


N/A 


M 


M 


NG1.SC.33 


FP Audio type 6b (internal conference) 


5.6 [211 


N/A 








NG1.SC.34 


Adaptive volume control for FP 


5.6 [21] 


N/A 








C701 : Status defined by clause 6.3, table 2. 



C702: At least one should be provided. C703:At least one should be provided. C704:IF Service NG1 .5 

(Superwideband) THEN M ELSE I. 
C705: IF Service NG1 .5 (Superwideband) THEN O ELSE I. 
C706: At least one should be provided. 

C707: IF feature NG1 .SC.23 (FP type 1 b) OR NG1 .SC.27 (FP type 3) THEN O ELSE I. Either NG1 .SC.24 or 

NG1 .SC.25 may be provided, but not both at the same time. 
C708: At least one should be provided. 

C709: IF feature NG1 .SC.28 (FP type 4) OR NG1 .SC.29 (FP type 5) THEN O ELSE I. Either NG1 .SC.30 or 
NG1 .SC.31 may be provided, but not both at the same time. 



NOTE 1: Testing specification for audio features, including handsfree, is provided in EN 300 176-2 [10]. 

NOTE 2: PP types lc, Id, 2b and 2c are based on HATS methodology. This methodology provides objective test 
results more consistent with subjective tests compared to artificial ear methodology. 

NOTE 3: All audio types used in the present document are compatible with VoIP or long delay networks. 



6.9 Application features 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following Application 
features: 



Table 8: Application features status 



Feature supported 




Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


R/B 


P 


NG1.A.1 


Easy PIN code registration 


5.7 


M 


O 


N/A 


NG1.A.2 


Easy pairing registration 


5.7 


M 


M 


N/A 


NG1.A.3 


Handset locator 


5.7 


M 


O 


O 


GAP.A.1 


AC bitstring mapping 


4.3 [12] 


M 


M 


M 


GAP.A.2 


Multiple subscription registration 


4.3 [12] 


M 


N/A 


N/A 


GAP. A. 3 


Manual entry of the PARK 


4.3 [12] 


O 


N/A 


N/A 


GAP. A. 4 


Terminal identity number assignment in mono cell system 


4.3 [12] 


O 


O 


N/A 
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6.1 Network (NWK) feature to procedure mapping 

The NWK features to procedure mapping of EN 300 444 [12] (GAP), clause 6.7 with the following changes and 
additional features shall apply: 



Table 9: NWK feature to procedure mapping 



Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 


R/B 


P 


NG1.N.1 Codec Negotiation 




5.2 [21] 


M 


M 


M 


Exchanqe of codec list durinq registration 
and location registration 


7.3.1 [21] 


M 


M 


M 


Basic service wideband speech and 
default attributes 


7.3.2 [21] 


M 


M 


M 


Codec Negotiation during call 
establishment 


7.3.3 [21] 


M 


M 


M 


NG1 .N.2 Codec Switching 




5.2 [21] 


M 


M 


M 


Codec Change 


7.3.4 [21] 


M 


M 


M 


Slot type modification 


7.3.5 [21] 


M 


M 


M 


MAC layer advanced connection slot type 
modification 


7.6.7 [21] 


M 


M 


M 


MAC layer connection type modification: 
basic to/from advanced 


7.6.6 [21] 


M 


M 


M 


NG1 .N.3 Missed call notification 




5.2 


M 


M 


M 


Generic events notification, general 


7.4.1.1 


M 


M 


M 


Missed call notification 


7.4.1.3 


M 


M 


M 


NG1 .N.4 Voice message waiting 
notification 




5.2 


M 


M 


M 


Generic events notification, general 


7.4.1.1 


M 


M 


M 


Voice message waiting notification 


7.4.1.2 


M 


M 


M 


NG1.N.5 Date and Time 
synchronization 




5.2 


M 


M 


M 


Date and Time synchronization 


7.4.2 


M 


M 


M 


Date and Time recovery 


7.4.20 


O 


O 


O 


NG1.N.6 Parallel Calls 




5.2 


M 


M, 
note 2 


O 


Parallel call common requirements 


7.4.3.1 


M 


M 


M 


Control messages 


7.4.3.2 


M 


M 


M 


Sending Keypad information 


8.10 [12] 


M 


M 


M 


Codec change for parallel calls 


7.4.3.3 


M 


M 


M 


Sendinq neqative acknowledqement 


7.4.3.4 


M 


M 


M 


Busy system or line notification 


7.4.8.3 


M 


M 


M 


NG1 .N.7 Common parallel call 
procedures (external or internal) 




5.2 


M 


M, 
note 2 


O 


Outgoing parallel call initiation (external 
or internal) 


7.4.3.5.1 


M 


M 


M 


Call waiting indication (external or 
internal) 


7.4.3.5.2 


M 


M 


M 


Call toggle (external or internal) 


7.4.3.5.3 


M 


M 


M 


Call release and call release rejection 


7.4.3.5.4 


M 


M 


M 


Call waiting acceptance (from PP to FP) 


7.4.3.5.6 


M 


M 


M 


Call waiting rejection (from PP to FP) 


7.4.3.5.7 


M 


M 


M 


Active call release with replacement (from 
PP to FP) 


7.4.3.5.12 


O 


M 


M 


Putting a call on hold 


7.4.3.5.8 


O 


M 


M 


Resuming a call put on hold 


7.4.3.5.9 


O, 
note 6 


M 


M 


CLIP on call waiting indication 


7.4.3.5.10 


M 


M 


M 


CNIP on call waiting indication 


7.4.3.5.11 


M 


M 


M 


Call remote status notification 


7.4.3.5.13 


O 


O 


O 
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Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 


Hid 


n 

r* 


NG1 .N.8 Call transfer (external or 
internal) 






M 


M 





Announced call transfer 


7.4.3.6.1 


M 


M 


M 


Unannounced call transfer 


7.4.3.6.2 


M 


M 


M 


Call re-injection to the system (external or 
internal) 


7.4.3.6.3 


M 


M 


M 


Remote party CLIP on call transfer 


7.4.3.6.4 


M 


M 


M 


Remote party CNIP on call transfer 


7.4.3.6.5 


M 


M 


M 


NG1 .N.9 3-party conference call 
(external or internal) 




5.2 





0, 
note 1 


0, 
note 1 


3-party Conference with established 
internal and external calls 


7.4.3.7 


M 


M 


M 


NG1.N.10 Intrusion call 




5.2 


O 


o, 

note 1 


o, 

note 1 


— ; ; ; 

Implicit intrusion call into a line in "single 
can moue 


1 A O O H 

/ .4. o.o.l 


O901 


M 


M 


Explicit intrusion call (from PP to FP) 


7.4.3.8.2 


C901 


IVI 


IVI 


NG1 .N.1 1 Call deflection (internal 
or external) 






U 


0, 
note 1 


0, 
note 1 


Call deflection (internal) 


1 A A O 

1 AA.d. 


M 


M 


M 


Call deflection (external) 


7.4.4.2 


M 


M 


M 


Call deflection control messages 


7 AAA A 


M 


M 


M 


NG1.N.12 Line identification 




5.2 


M 


M 


M 


Line identification general requirements 


7.4.5.1 


M 


M 


M 


General line identification requirements 
for external outgoing calls 


7.4.5.2.1 


M 


M 


M 


Line identification for a first external 
outgoing call using «CALL-INFO» IE 


7.4.5.2.2 


M 


M 


M 


Line identification for a first external 
outgoing call using «MULTI-KEYPAD» 
IE 


7.4.5.2.3 


I 

(note 5) 








FP managed line selection for a first 
external outgoing call 


7.4.5.2.4 


M 


M 


M 


General line identification requirements 
for external incoming calls 


7.4.5.3.1 


M 


M 


M 


Line identification for a first external 
incoming call 


7.4.5.3.2 


M 


M 


M 


NG1.N.13 Call identification 






M 


M 


Kyi 
IVI 


— — : 

Call identifier general requirements 


1 A c ^ 
/ .4.0.1 


M 


M 


M 


Call identifier assignment on outgoing call 

/CD DDI 

(rr to rr) 


7.4.6.2 


M 


M 


M 


Call identifier assignment on incoming 
call (FP to PP) 


7 /I C Q 
/.4.D.O 


M 


M 


M 


Call status indication to the handset 


~7 A P. A 


IVI 


M 


M 


NG1.N.14 Multiple lines 




5.2 


M 








Multiple lines common requirements 


7.4.7.1 


M 


M 


M 


Terminal attachment and line settings 


7.4.7.2 


M 


M 


M 


Incoming and outgoing external calls on a 
multiple line system 


7.4.7.3 


M 


M 


M 


Internal calls in multiple line context 


7.4.7.4 


M 


M 


M 


Compatibility with non multiple line PP or 
FP 


7.4.7.5 


M 


M 


M 
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Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 


R/R 
Pi d 


D 


Mf^1 M 1 ^ Mi iltinlp nallc 
I .IN. I IVIUIlipic Odllb 




D.tL 


IVI 


IVI 






iviuiupic odiib yciicidi ic^uirciiiciub 


7 4 ft 1 

/ .4.O. I 


IVI 


M 
IVI 


IVI 




incoming ana ouigoing exiernai cans on a 

mi iltinlo nail lino 

IIIUILI|JIC L-dll Mile 


7 A ft 
/ . 4. o.£- 


l\/l 
IVI 


IVI 


M 
IVI 




Ri iqv QWQtpm nr linp nntifinatinn 

UUoV OyOLCI 1 1 U 1 Mile IIULIIIOdLIUII 


7 4 8 ft. 


M 


M 


M 


INVJ I .IN. I U l_loL ClLfLfCOO OCI VIUC 






M 


M 


o 




Hpnpral nnnQirlpratinnQ 

UCI ICI dl L-UI lolUC 1 dUU 1 lo 


7.4.1 0.1 


M 


M 


M 




1 ict rhanno nntifinatinn 

l_loL Ol Idl ILJC IIULII lOdLILM 1 


7 4 1 n ? 




M 


M 




OLdl L / CI IU odoolUI 1 ^1 IULC *T J 


7.4.1 0.4.1 


M 


M 


M 




fli ipt\/ qi innnrtpH orttru fiplHQ fnntp A\ 
wuci y oU|J|jui lcu ci ili y i iciuo y\ hjlc *t) 


7.4.1 0.4.2 




M 


M 




Read entries (note 4) 


7.4.10.4.3 


M 


M 
IVI 


M 
IVI 




tun entry (note 4) 




m 

IVI 


M 


M 




Save entry (note 4) 


7.4.10.4.5 


M 


M 


M 




Delete entry (note 4) 


I A. \ U.4.D 


l\ /I 

M 


M 


U 




Delete list (note 4) 


7 A -\ C\ A ~7 


M 


M 


M 




Search entries (note 4) 


7.4.10.4.8 


M 


M 


M 




Negative acknowledgement 


7.4.1 0.4.9 


M 


M 


M 




Data packet / Data packet last 


7.4.10.4.10 


M 


M 


M 




DECT system and line settings 
considerations 


7.4.1 1 .1 


M 


M 


o 




Interactions between registration, 
aiiacnrneni ot nanoseis ana iists 


"7 yl H H O 


M 


M 


u 




rlfcJIUb UcbOlipLIUll 


7 4 1 n ^ 1 
/ .4. I U.O. I 


M 
IVI 


IVI 


IVI 




Aknnr m o 1 roloooa in nooa nf ("•oil coti in 
MUllUlllldl iclcdbc 111 Odbc Ul Odll bcLUp 

nnlliQinnQ fnntp ~7\ 

OUIIIolUI lo \l IULC / J 


Q c o o rn 


w 


w 


n 




rSunnortPd li^t^l 












List of Supported Lists 


7.4.10.5.2 





M 


M 




Missed Calls List 


7.4.10.5.3 


M 


M 


M 




Outgoing Calls List 


7.4.10.5.4 













Incoming Accepted Calls List 


7.4.10.5.5 


M 


M 


M 




All Calls List 


7.4.10.5.6 













Contact List 


7.4.10.5.7 


M 


M 


M 




Internal Names List 


7.4.10.5.8 


M 


M 


M 




All Incoming Calls List 


7.4.10.5.11 
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Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 


R/R 
Pi d 


p 




nCPT Qwctom Qottinnc 1 ict 
UCL/ 1 oyblclil OcUlliyb Llbl 


/ .4. I I .o 


M 
IVI 


M 
IVI 


n 




Llile ocLlliiyb LlbL 


/ .4. I 1 .4 


M 
IVI 


IVI 


n 




viiTuai L/Onxaci list ana oaii list per 

1 ino 
■ 1 1 IC 


7 A 1 1 £ 
/ .4. I I .0 










r^iinnnrtpri DEf!T ^v^tpm ^pttinn^l 

[wuuuui icu t-J i— w i o y dici 1 1 ocuii i^oj 












Piirrpnt PIM poHp 

W U 1 1 C 1 1 L 1 1 1 N LUUC 


7.4.1 1 .3.1 


M 


M 


o 




Plnpk mactpr 

\_/IUUI\ llldoLCI 


7.4.1 1 .3.2 


M 


M 


o 




Ddoc 1 cbc L 


7 A ii 9 9 


M 

IVI 


M 


o 




pp |p QHHrpcc / tvnp 
\\ ii duui coo / iy |JC 


7.4.1 1 .3.4 


o 




o 




FP IP arlrlrPQQ / vpIiio 

1 1 ll aUUI COO / VCIIUC 


7.4.1 1 .3.5 


o 




o 




FP IP arlrlrPQQ / Qiihnpt maQk 

1 1 II ClUUI COO / OUUIICL II IClOlx 


7.4.1 1 .3.6 


o 


o 


o 




FP IP airlHrocc / natow/aw 
rr in duuicoo / ydicvvay 


7 A ii 9 7 


Ci 

w 




n 




pp ip arlrlrPQQ / RM^ cpr\/pr 
rr 1 1 auui coo / lvi no ocivci 


7 A ii 9 8 

/ 1 1 .O-O 


n 








FP vprcjinn / Firmwaro \/or<5inn 

\ \ VCIolUII / 1 IllllvVdIC VCIOIUII 


7.4.1 1 .3.9 


M 


M 






FP x/prcinn / FFnrnm vorQinn 
in vcioiuii / i_i_uiuiii vcioiuii 


7.4.1 1 .3.10 


M 


M 






FP \/orcir»n / 1— larH\A/3r"o \/orcinn 
rr vcioiuii / nciiuvvciiC vcioiuii 


7 A ii 9 11 

/ .t. I I .O. 1 1 


n 

w 


n 






Fmiccirtn mnrlo 
l^i 1 1 looiui i iiiuuc 


7 A ii 9 1? 

/ I I .O- 1 C- 


PQD9 


npn9 






Npw PIN rnrlp 

InCVV iiim uuu c 


7 4/1 -| .3.13 


M 


M 






r^unnnrtpH linp ^pttinn^l 












1 ino namo 
i— ll ic i idi i ic 


7 A ii 4 1 

/ I I .t. 1 


IVI 


IVI 






1 ino iH 

I 1 1 IC IU 


7 A ii 4 ? 


M 

IVI 


M 


o 




AALLdUl ICU 1 Idl lUoCLO 


7.4.1 1 .4.3 


M 


M 






niallinn nrofiy 

l_/ 1 d 1 1 1 1 1 LJ UICIIA 


7.4.1 1 .4.4 


o 








FP molnHv 
rr ii iciuu y 


7 4 11 4 R 


o 








FP \/nli i mo 
r r vuiui i ic 


7 4 11 4 fi 




o 


o 




RlnrkpH niimhpr 


7.4.1 1 .4.7 


o 








Mi iltinlo fallc mnrlo /"cinnlo/mi iltinlo^ 
iviuiliuic udiio iiiuuc \oii ly ic/ 1 1 iuiuuic/ 


7 4 11 4 S 


M 

IVI 


IVI 


IVI 




Intn icir\n foil 
II III UolUI 1 udll 


7 4 11 4 Q 


oyu4 


wi/U4 


oyvj4 




Pormanont PI IR 
r ci 1 1 idi ici il uLin 


7.4.1 1 .4.10 










Pall fonA/arrlinn 1 Inrrinrli+innal 

wdll lUIVVdlUlliy U 1 IUU 1 IU 1 LIUI Idi 


7.4.1 1 .4.1 1 


IVI 


M 


1 




Call forwarding on No Answer 


7.4.11.4.12 


M 


IVI 


1 

1 




oan Torwarumg on ousy suDScriDer 


7.4.1 1 .4.13 


IVI 


M 


1 


NG1.N. 17 Calling line identity 




5.2 





O 


(J 


restriction 


Considerations 


"7 A H O H 

7.4.1 <L.\ 


M 


M 







Permanent CLIR mode (all calls) 


7AA2.2 


M 


M 







— T- 1 in 1 / II 1 ll\ 

Temporary CLIR mode (call by call) 


7.4.12.3 


M 


N/A 





NG1 .N.1 8 Call forwarding 




5.2 


M 


M 


1 


(external calls) 


Call Forwarding common requirements 


7.4.13.1 


M 


M 


1 




External Call Forwarding Unconditional 
(CFU) to external number 


7.4.13.2 


M 


M 


1 




External Call Forwarding on No Answer 
(CFNA) to external number 


7.4.13.3 


M 


M 


1 




External Call Forwarding on Busy 
subscriber (CFB) to external number 


7.4.13.4 


M 


M 


1 


NG1 .N.1 9 DTMF handling 




5.2 


M 


M 


o 




Uplink DTMF transmission at call setup 
when FP connected to classic switching 
network 


7.4.14.1 .1 


M 


C906 


C906 




Uplink DTMF transmission when 
connected 


~7 A 1 A 1 O 
1 .4.1 4.1 


M 


M 







Downlink DTMF reception 


7.4.14.2 


M 


M 







Local DTMF feedback of dialled digits 


7.4.14.3 


M 


M 





NG1 .N.20 Tones provision 




5.2 


M 


M 







General considerations 


7.4.15.1 


M 


M 







Tones provision by the system 


7.4.15.2 


M 


M 







Transparency to tones provision by the 
network or PABX 


7.4.15.3 


M 


M 
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Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 


R/B 


P 


NG1.N.21 Headset management 




5.2 


C907 


IVI 


r\ 
U 


Headset considerations 


/ .4.1 D.1 




M 





Headset call interception 


7.4.16.2 


C907 


M 





Headset incoming call 


7.4.16.3 


C907 


M 





Re-dial of last outgoing call 


7.4.16.4 


C908 


M 





Re-dial of last incoming call 


7.4.16.5 


C908 


M 





Switching from headset to handset 
(headset initiated) 


7.4.16.6 


C908 


M 





Switching from headset to handset 
(handset initiated) 


7.4.16.7 


C909 


M 





Compatibility with other telephony 
features and profiles 


7.4.16.8 


C907 


M 





NG1 .N.22 Handling of lines where 
second calls are signalled in-band 




5.2 


M 



note 2 





General requirements 


7.4.3.10.1 


I 


M 


M 


Basic 'double call with in-band signalling' 
lines 


7.4.3.10.2 


I 


M 
note 3 


M 


Off-hook CLIP enabled 'double call with 
in-band signalling' lines 


7.4.3.1 0.3 


M 


M 
note 3 


M 


Use of transparent commands on DCIBS 

llllcb ^DdblO Ol \J\\ llOOr\ L/Llr cildUlcUj Oi 

any other line 


"7 A O H f~\ A 
f A.O.I U.4 


M 


M 


i\/i 

M 


OMr.lN. I wUiyOlliy Odll 




A 1 M 91 


M 
IVI 


IVI 


M 
IVI 


uuigoing can request 




l\/l 
IVI 


l\/l 
IVI 


IVI 


uvenap senaing 


O.O [ 1 £.\ 


IVI 


n 


n 


^myouiy can pruceeuiny 


ft A M Ol 


IVI 


n 




^uiyoiny odii coriiiriiiduoii 


R ^ T1 91 
O.O [ I ^.J 


IVI 




n 


^uigoing can connection 


q c fl 91 


KA 
IVI 


M 


M 


Sending keypad information 


8.10 [12] 


M 


M 


IVI 


Abnormal release in case of call setup 
conibioiib ^noie / ) 


Q C O Q rci 
y.o.^.o [Oj 


u 


U 


r\ 
U 


GAP.N.8 Incoming call 




4.1 [I^J 


IVI 


IVI 


IVI 


incoming can request 




KA 
IVI 


Kyi 

IVI 


IVI 


INGOllllliy Odll COillllllldLIOll 


O HO HOI 
O. 1 O [ 1 £.\ 


M 
IVI 


IVI 


Kyi 

IVI 


r 1 dieillily 


O. 1 "f [ 1 £lj 


IVI 


Kyi 

IVI 


IVI 


incoming can connection 


O. I [ I d\ 


\A 
IVI 


IVI 


Kyi 

IVI 


MDnormai release in case or can setup 

pnlliQinnQ fnntp 7^ 

L-UlllolUI lo yl IULG / y 


QCOQ r^i 






<j 


GAP. N. 11 Location registration 




4 1 M?l 


M 




M 


1 npatinn rpniQtratinn 

l_UL<dLIUI 1 1 CyioLI dLIUI 1 




M 


M 


M 


1 nr*3tinn i irirlatp 

l_UL/dLIUII U|JUdLc 




M 

IVI 






Tprminal f^anahilitv inrlicatinn 

1 CI II III ICll wafJdUl 1 1 Ly II IU lUdLIU 1 1 


7.4.9.1 


M 


M 


M 


1 ncatinn rpni<5tratinn pftpr rp-lnpk 

1— UlrdLIUI 1 1 ey 1 o LI dLIUI 1 dlLCl IC IUUr\ 


7.4.1 8 


M 


N/A 


N/A 


GAP.N.14 Service class 
indication/assignment 




4 1 n?l 


M 




M 


Ohtaininn arrocc rinhtc 

wULdll III ILj dL/UOOO liyillo 


O.OU [ 1 C-\ 


M 

IVI 


M 

IVI 


M 

IVI 


Tprminal f~*pnahilit\/ inHicatinn 

1 tfl 1 1 II 1 Idl wdUaUl 1 1 Ly IMUIUdLIUII 


7 4 Q 1 


M 

IVI 


M 


M 


Ai ithpntipatinn nf PP iiQinn H^AA 

r^Ull ici lllOdUUl l KJ\ i i Uoll ly L/OrArA 


8 94 T1 91 


M 


M 


M 


Ai ithpntiratinn nf PP iicjinn D^AAP 

AAULI ICI ILIUallUI 1 Ul i I Uoll ly \-J \Dr\f\C- 


8 ?4 M 91 




npi o 




fiAP MIR Alprtinn 




41 n9i 


M 

IVI 


M 

IVI 


M 

IVI 


PT Alprtinn 

r 1 /Alcl Lll ly 


8 1 4 M 91 


IVI 


M 


M 


PX Alprtinn iiQinn nattprn Qinnallinn 
i i rAiciLiiiy uoii ly udLieiii oiyiidiiniy 


7.4.19 


M 


M 


M 


GAP N 16 ZAP 




4 1 n2i 


M 








Obtaining access rights 


8.30 [12] 


M 


M 


M 


Terminal Capability indication 


7.4.9.1 [12] 


M 


M 


M 


Incrementing the ZAP value 


8.26 [12] 


M 


M 


M 


Authentication of FT using DSAA 


8.23 [12] 





M 


M 


Authentication of FT using DSAA2 


8.45.6 [12] 


C911 


C910 


C910 


GAP.N.18 Subscription 
registration user procedure on-air 




4.1 [12] 


M 


M 


M 


Obtaining access rights 


8.30 [12] 


M 


M 


M 


Terminal Capability indication 


7.4.9.1 


M 


M 


M 
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Feature/Procedure mapping 





Status 


Feature 


Procedure 


Reference 


PT 


FT 


R/B 


p 


RAP N 1Q I ink mntrnl 

\J r\ 1 .IN. Iv7 L_l 1 lr\ \jD 1 1 LI U 1 






M 


M 


M 


Inrlirppt FX initiatprl link PQtahliQhmpnt 

II IU 1 1 CO l \ 1 1 1 1 1 MdlCU 1 1 1 1 r\ Co LaUl 1 o 1 1 1 1 1 C 1 1 L 


7 "3 ft T911 

/ -O.O \C- I J 


M 


M 


M 


r^iro^t PT initiator! link octahlichmont 

L/l 1 COL I 1 II II LldLcU 1 1 1 lr\ Cb LdUl lol II 1 1 cl 11 


O.OU [ 1 


M 

IVI 


M 

IVI 


IVI 


1 ink roliaaco "nnrmal" 
l_llll\ 1 clcdbc MUlllldl 


ft ^7 n 91 


M 

IVI 


M 


M 


1 ink rplpaQP "ahnnrmal" 

l_lllr\ 1 clcaod aU 1 1 U 1 1 1 1 d 1 


8 ^a n ?i 

U.JO [ 1 £.J 


M 


M 


M 


1 ink tpIpsqp "maintain" 

l_lllr\ 1 Clcaod llldlllLdlll 




M 


M 


M 


GAP. N. 24 Signalling of display 
characters 








n 




r^icnlav/ 
uio|Jidy 


a 1 r n ?i 


M 

IVI 


M 


M 


Xprminal panahilitv inrlipatinn 
iciiiinidi L/dLJdUi ii iy n luioduui i 


7.4.9.1 


M 


M 


M 


GAP. N. 25 Display control 
charactprs 




4 1 n?i 








r^icnlav/ 
\-J\o\J\ay 


ft 1 fi M 91 


K/l 

IVI 


K/l 

IVI 


Kyi 

IVI 


Xorminal fanaHilitw inrlinatinn 

1 CI II Ml ldl Ud(JdUIIILy II lUIUdLIUI 1 


7 / q 1 


K/l 

IVI 


M 


M 


GAP.N.31 Internal Call 




4.1 [12] 


M 


IVI 


Kyi 

IVI 


INlUllldl Odll bciup 


7 o ro -j l 
/ .o.O \c. 1 J 


K/l 

IVI 


IVI 


K/l 

IVI 


inTerridi can Keypad 


Q 1 Q M 91 


IVI 






Intornol r-i 1 1 f"M IP 

iruGrnai can oi_ir 


q /iq noi 
o.4o [ I 


IVI 


Kyi 

IVI 


Kyi 

IVI 


Infornnl r^n 1 1 f"*MIP 

irucrnai can oiNir 


q /i/i n oi 

0.*+*+ [ 1 d-\ 


k/i 

IVI 


IVI 


K/l 

IVI 


INlcnldl Cdll GUUcG priUilLy 


74OQ 


Kyi 

IVI 


Kyi 

IVI 


Kyi 

IVI 


U 1 r-O OINIr 


7/117 


K/l 
IVI 


IVI 


Kyi 

IVI 


GAP. N.34 Calling Name 

I rlpntifi ration Prp^pntptinn ff^NIP^ 

IUCIILIIIL>dLIUII 1 1 CaCI 1 la LI U 1 1 'ill ^ 




4.1 [I^J 


K/l 
IVI 


IVI 


Kyi 

IVI 


ailing Ma mo IHontifir*atir»n P roco ntatinn 
Odllliiy iNdlilc lucl 1 LI 1 ICdllUI 1 r 1 cbcl ILdUUI 1 

(CNIP) Indication 


O /IO M Ol 

0.*+t [ 1 


K/l 

IVI 


M 


M 


UTF-8 CNIP 


7.4.17 


M 


M 


M 


GAP. N. 35 Enhanced security 




4.1 [12] 


M 


M 


M 


Encryption of all calls 


8.45.1 [12] 


M 


M 


M 


Re-keying during a call 


8.45.2 [12] 











Early encryption 


8.45.3 [12] 











Subscription requirements 


8.45.4 [12] 


M 


M 


M 


Behaviour against legacy devices 


8.45.5 [12] 


M 


M 


M 



C901 : At least one of the two procedures 7.4.3.8.1 OR 7.4.3.8.2 shall be implemented. 
C902: IF NG1 .N.14 THEN "0" ELSE "I". 
C903: IF NG1 .M.5 THEN "M" ELSE "I". 
C904: IF NG1 .N.10 THEN "M" ELSE "I". 
C905: IF NG1 .N.17 THEN "M" ELSE "I". 

C906: IF FP is connected to classic switching networks (PSTN for example) THEN "M" ELSE "N/A". 
C907: IF the PT is a headset PP THEN "M" ELSE "I". 
C908: IF the PT is a headset PP THEN "O" ELSE "I". 
C909: IF the PT is a headset PP THEN "I" ELSE "0". 
C91 0: IF feature GAP.N.36 THEN M ELSE I. 

C91 1 : IF feature GAP.N.36 THEN O ELSE I. 

NOTE 1 : If the corresponding feature is not supported on FT side, the FT shall however implement the "sending 

negative acknowledgement" procedure (see clause 7.4.3.4). 
NOTE 2: All procedures of NG1 .N.6 and NG1 .N.7 shall apply to all FTs and for all line types (full parallel call 

compliant lines and DCIBS lines). For DCIBS lines, the FT shall implement in addition NG1 .N.22 feature, 

which describes some amendments to NG1 .N.6 and NG1 .N.7 for such lines. A given FT shall be 

designed to handle both line types, or only one of them. 
NOTE 3: Both procedures are M for the FP. However, for a given line, only one of the procedures 7.4.3.1 0.2 or 

7.4.3.10.3 is used. 
NOTE 4: See also clause 7.4.10.4 for details per list. 

NOTE 5: This procedure is provisioned for GAP and Part 1 PPs and is irrelevant for Part 3 PPs. 

NOTE 6: The procedure "Resuming a call put on-hold" is optional for the PP. However the corresponding control 

message is mandatory for PPs since it may be needed by the call release procedure (see 

clause 7.4.3.5.4). 

NOTE 7: If implemented, the procedure shall be implemented for all types of calls: outgoing calls (GAP.N.1 ), 
incoming calls (GAP.N.8) and LiA service calls (NG1 .N.1 6). 
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6.1 1 Data Link Control (DLC) Service to procedure mapping 

The DLC service to procedure mapping of EN 300 444 [12] (GAP), clause 6.8.1, with the following changes and 
additional services shall apply: 



Table 10: DLC service to procedure mapping 



Service/Procedure mapping 




Status 


Service 


Procedure 


Reference 


PT 


FT 


R/B 


P 


NG1.D.1 LU1 Transparent 
Unprotected service (TRUP) 
Class 0/minimum_delay 




5.3 [12] 


M 


M 


M 


LU1 Transparent Unprotected service 
(TRUP) operation 


1 1 .2 [4] 


M 


M 


M 


Class 0: No Lu x retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


Minimum delay (speech) operation 


14.2.3 [4] 


M 


M 


M 


LLME U-plane establishment 


9.9.1 [12] 


M 


M 


M 


NG1.D.2 LU1 Transparent 
Unprotected service (TRUP) 
Class 




5.3 [21] 


C1001 


C1001 


C1001 


LU1 Transparent Unprotected service 
(TRUP) operation 


1 1 .2 [4] 


M 


M 


M 


Class 0: No Lu x retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


LLME U-plane establishment 


9.9.1 [12] 


M 


M 


M 


NG1 .D.3 LU7 64 kbit/s protected 
bearer service 




5.3 [21] 


C1001 


C1001 


C1001 


LU7 DLC layer service 


11.9.4 [4] 


M 


M 


M 


NG1.D.4 LU12 LU 12 Unprotected 
Framed service (UNF) Class 




5.3 [12] 


C1001 


C1001 


C1001 


LU12 UNprotected Framed service (UNF) 
operation 


11.14 [4] 


M 


M 


M 


Class 0: No Lu x retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


LLME U-plane establishment 


9.9.1 [12] 


M 


M 


M 


NG1.D.5 FU1 DLC frame 




5.3 [12] 


M 


M 


M 


FU1 frame operation 


8.19 [12] 


M 


M 


M 


FU1 frame structure 


12.2 [4] 


M 


M 


M 


NG1.D.6 FU7 DLC frame 




5.3 [12] 


C1001 


C1001 


C1001 


FU7 frame structure 


11.9.4.2 [4] 


M 


M 


M 


NG1 .D.7 FU12 DLC frame with 
adaptation for codec G.729.1 




5.3 [12] 


C1001 


C1001 


C1001 


FU12 frame structure 


12.12 [4] 


M 


M 


M 


Annex for codec G.729.1 


E.1 [4] 


M 


M 


M 


FU1 2 frame operation 


7.5.2 [12] 


M 


M 


M 


C1 001 : Status defined by clause 6.3, table 2. 
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6.12 Medium Access Control (MAC) service to procedure 
mapping 

The MAC service to procedure mapping of EN 300 444 (GAP) [12], clause 6.8.2, with the following changes and 
additional services shall apply: 



Table 11 : MAC service to procedure mapping 



Service/Procedure mapping 




Status 


Service 


Procedure 


Reference 


PT 


FT 


R/B 


P 


NG1.M.1 lN_minimum delay 
symmetric MAC service type 




5.4 [21] 


M 


M 


M 


MAC layer procedures: general 


7.9.1 [21] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


l N _minimum delay symmetric MAC service, 
type 1 


5.6.2.1 [3] 


M 


M 


M 


NG1.M.2In normal delay 
symmetric MAC service type 




5.4 [21] 


O 


O 


O 


MAC layer procedures: general 


7.9.1 [21] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


l N _normal delay symmetric MAC service 
type 2 


5.6.2.1 [3] 


M 


M 


M 


NG1.M.3 lpo_error_detection 
symmetric MAC service type 




5.4 [21] 


O 


O 


O 


MAC layer procedures: general 


7.9.1 [21] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lp_error_detection symmetric MAC service 
type 3 


5.6.2.1 [3] 


M 


M 


M 


Single-subfield protected format 


6.2.1.3.4 [3] 


M 


M 


M 


NG1 .M.4 Advanced connections 




5.4 [21] 


M 


M 


M 


Setup of advanced connection, bearer 
setup (A-field) 


7.6.5 [21] 


M 


M 


M 


Connection type modification: basic to/from 
advanced 


7.6.6 [21] 


M 


M 


M 


Slot type modification 


7.6.7 [21] 


M 


M 


M 


Service type modification 


7.6.8 [21] 


C1101 


C1101 


C1101 


ECN number modification 


7.6.9 [21] 


C1102 


C1102 


C1102 


Connection/bearer release 


7.6.10 [21] 


M 


M 


M 


NG1 .M.5 "no-emision" mode 




5.4 


O 


O 


O 


Tail identification for "no emission" mode 


7.1.2 [3] 


M 


M 


M 


Extended Physical and Mac layer 
capabilities (part 2) bit a23 


7.2.3.11 [3] 


M 


M 


M 


Bearer handover/replacement information, 
multiframe-countdown 


7.2.4.3 [3] 


M 


M 


M 


"no emission" mode sync information 


7.3.5.3 [3] 


M 


M 


M 


"no emission" mode procedures 


9.4 [3] 


M 


M 


M 


Management procedures for "no emission" 
mode 


11.11 [3] 


M 


M 


M 


GAP.M.2 Continuous broadcast 




5.2 [12] 


M 


M 


M 


Downlink broadcast 


7.6.3 


M 


M 


M 


Higher Layer information FP broadcast 


7.4.9.2 


M 


M 


M 
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Service/Procedure mapping 





Status 


Service 


Procedure 


Reference 


PT 


FT 


n/b 


r 


— ; 

GAP.M.3 Paging broadcast 




C O M on 

5.2 [12] 


iv yi 


M 


M 




Paging broadcast 


7.6.4 [21] 


M 


M 


M 














GAP.M.9 Bearer handover, 
intra-cell 




5.2 [12] 


M 


C1103 


C1103 




Bearer handover request 


7.6.1 1 [21] 


M 


M 


M 


GAP. M. 10 Bearer handover, 
inter-cell 




5.2 [12] 


M 


O 


O 






Bearer handover request 


/.b.1 1 [^1J 


M 


iv yi 
M 


M 


— ; 

GAP. M. 11 Connection handover, 

llllld Ocll 




5.2 [12] 


M 


r»i 1 r\A 


f 1 1 r\A 




c\ n r>Qft+i/-»r> hanrlnwor ro/-ii loot 

^ui H loouuii iidiiuuvyr rt;qut?bi 


7 c io roil 


IUI 
IVI 


IVI 


IVI 


vjMr.ivi. i d. oonneciion ncinciover, 
intpr-ppll 

1 1 1 LCI bU 1 1 




£ M 01 


IVI 








Connection handover request 


7.6.12 [21] 


M 


M 


M 


GAP. M. 13 SARI support 




5.2 [12] 


M 


O 







Downlink broadcast 


7.6.3 


M 


M 


M 




Higher Layer information FP broadcast 


7.4.9.2 


M 


M 


M 


GAP. M. 15 Re-keying 




5.2 [12] 


C1105 


C1105 


C1105 




Re-keying 


10.17 [12] 


M 


M 


M 


GAP. M. 16 Early encryption 




5.2 [12] 


C1106 


C1106 


C1106 




Early encryption 


10.18 [12] 


M 


M 


M 



C1101: IF service NG1.4 OR NG1.5 OR NG1.6 OR NG1.2 IA II OR NG1.2 IA III THEN M ELSE O. 

C1 102: IF multiple connection between the same PT-FT pair THEN M ELSE O. 

C1 103: IF service GAP.M.1 1 THEN O ELSE M. 

C1 104: IF service GAP.M.9 THEN O ELSE M. 

C1 105: IF NWK layer procedure "Re-keying during a call" is implemented THEN M ELSE O. 

C1 106: IF NWK layer procedure "Early encryption" is implemented THEN M ELSE O. 
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6.13 Application feature to procedure mapping 

The Application feature to procedure mapping of EN 300 444 [12] (GAP), clause 6.8.3, with the following changes 
shall apply: 



Table 12: Application feature to procedure mapping 



Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 


R/B 


P 


NG1.A.1 Easy PIN code 
registration 




5.7 


M 


O 


N/A 


Registration mode automatic access 


7.10.1.3.1 


M 


N/A 


N/A 


Searching mode and PIN code requests 


7.10.1.1.1 


M 


N/A 


N/A 


Base station name selection 


7.10.1.3.2 


O 


O 


N/A 


Registration user feedback 


7.10.1.3.3 


M 


O 


N/A 


NG1.A.2 Easy pairing registration 




5.7 


M 


M 


N/A 


Easy pairing description 


7.10.1.2.1 


M 


M 


N/A 


Registration mode automatic access 


7.10.1.3.1 


M 


N/A 


N/A 


Base station limited registration mode 


7.10.1.2.2 


N/A 


M 


N/A 


Searching mode request 


7.10.1.2.3 


M 


N/A 


N/A 


Base station name selection 


7.10.1.3.2 


O 


O 


N/A 


Registration user feedback 


7.10.1.3.3 


M 


O 


N/A 


NG1.A.3 Handset locator 




5.7 


M 





O 


Handset locator 


7.10.2 


M 


M 


O 


GAP.A.1 AC to bitstring mapping 




4.3 [12] 


M 


C1201 


M 


AC to bitstring mapping 


14.2 [12] 


M 


M 


M 


GAP. A. 2 Multiple subscription 
registration 




4.3 [12] 


M 


N/A 


N/A 


Subscription control 


14.1 [12] 


M 


N/A 


N/A 


GAP. A. 3 Manual entry of the 
PARK 




4.3 [12] 


O 


N/A 


N/A 


Manual entry of the PARK 


14.3 [12] 


M 


N/A 


N/A 


GAP. A. 4 Terminal identity number 
assignment in mono cell system 




4.3 [12] 


O 


O 


N/A 


Terminal identity number assignment 


14.4 [12] 


M 


M 


N/A 


C1201: IF feature GAP.N.9 OR GAP. N. 10 OR GAP. N. 12 OR GAP. N. 26 THEN M ELSE N/A. 



6.14 General requirements 

6.1 4.1 Network (NWK) layer message contents 

The requirements of TS 102 527-1 [21], clause 6.14.1 shall apply. 

6.14.2 Transaction identifier 

The requirements of TS 102 527-1 [21], clause 6.14.2 shall apply. 

6.1 4.3 Length of a Network (NWK) layer message 

The requirements of TS 102 527-1 [21], clause 6.14.3 shall apply. 

6.1 4.4 Handling of error and exception conditions 

The requirements of TS 102 527-1 [21], clause 6.14.4 shall apply. 

6.1 4.5 Generic Access Profile (GAP) default setup attributes 

The requirements of TS 102 527-1 [21], clause 6.14.5 shall apply. 



ETSI 



46 ETSI TS 1 02 527-3 V1 .5.1 (201 3-03) 

6.14.6 Coexistence of Mobility Management (MM) and Call Control (CC) 
procedures 

The requirements of TS 102 527-1 [21], clause 6.14.6 shall apply. 

6.1 4.7 Coding rules for information elements 

The requirements of TS 102 527-1 [21], clause 6.14.7 shall apply. 



7 Procedure description 

The following clauses define the process mandatory procedures which are in the scope of the New Generation DECT 
wideband speech. Each procedure (if appropriate) is divided into three parts: 

a) normal (i.e. successful) case(s). This part defines the functions and respective protocol element values in 
normal operation; 

b) associated procedure(s). This is an integral part of the actual procedure (if defined in the present document), 
i.e. if a procedure is being declared to be supported, the respective entity shall also support the associated 
procedures, e.g. timer management, in the clause following the description of the normal case; 

c) exceptional case(s). This is an integral part of the actual procedure (if defined in the present document), i.e. if a 
procedure is being declared to be supported, the respective entity shall also support the exception handling 
defined in the clause following the description of the normal case. 

All protocol elements listed in the following clauses are process mandatory, i.e. the FT and PT depending on their role 
in the procedure shall send or shall receive and process the relevant protocol elements as listed in the respective tables if 
not explicitly stated as being optional. 

The primitives used in procedure descriptions are defined only for the purpose of describing layer-to-layer interactions. 
The primitives are defined as an abstract list of parameters, and their concrete realization may vary between 
implementations. No formal testing of primitives is intended. The primitive definitions have no normative significance. 

7.1 Backward compatibility with Generic Access Profile (GAP) 
and with New Generation DECT part 1 (wideband speech) 
equipment 

7.1 .1 Backward compatibility with Generic Access Profile (GAP); 
Requirements for NG-DECT, part 3 Fixed Parts (FPs) 

The FP shall support the GAP (EN 300 444 [12]) standard procedures (full slot and 

Recommendation ITU-T G.726 [15]). In other words, it shall inter-operate with a GAP compliant PP. The use of 
messages or information elements not known to GAP PPs is not recommended. 

NOTE 1 : The FP may detect the type of PP by means of the Information Element <Terminal Capability> provided 
at registration. 

NOTE 2: It should be noted that GAP compliant PPs may have a more relaxed requirement of TCLw than New 
Generation DECT part 3 devices. In some scenarios, when combining GAP terminals with poor TCLw 
with long delay networks (like VoIP) and insufficient echo cancellation in the network, audible echo 
could be perceived by the far end terminal. This problem is not specific of devices compliant with the 
present document. For more information refer to EN 300 175-8 [8], annex E. 
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7.1 .2 Backward compatibility with Generic Access Profile (GAP); 
Requirements for NG-DECT, part 3 Portable Parts (PPs) registered 
on GAP compliant FPs 

The PP shall use the GAP standard procedures (full slot and Recommendation ITU-T G.726 [15]) in front of GAP 
standard FP. In other words, it shall inter-operate with a GAP compliant FP. The use of messages or information 
elements not known to GAP FPs is not recommended. 

7.1 .3 Backward compatibility with New Generation DECT, part 1 ; 
Requirements for NG-DECT, part 3 Fixed Parts (FPs) 

The FP shall support DECT New Generation part 1 (TS 102 527-1 [21]) procedures. In other words, a DECT New 
Generation, part 3 Fixed part shall operate exactly as a DECT New Generation, part 1 FP for a New Generation Part 1 
PP. All features and services defined in TS 102 527-1 [21] shall be provided. The use of messages or information 
elements not known to New Generation DECT Part 1 PPs is not recommended. 

NOTE 1 : The FP may detect the type of PP by means of the Information Element <Terminal Capability> provided 
at registration. 

NOTE 2: It should be noted that New Generation DECT part 1 PPs may have a more relaxed requirement of TCLw 
than New Generation DECT part 3 devices. Note 2 of clause 7.1.1 may be also applicable this case. For 
more information refer to EN 300 175-8 [8], annex E. 

7.1 .4 Backward compatibility with New Generation DECT, part 1 ; 
Requirements for NG-DECT, part 3 Portable Parts (PPs) registered 
on NG-DECT Part 1 FPs 

The PP shall use the part 1 standard procedures (TS 102 527-1 [21]) in front of NG-DECT Part 1 FPs. The use of 
messages or information elements not known to New Generation DECT Part 1 FPs is not recommended. 

7.2 Generic Access Profile (GAP) procedures 

Unless otherwise noted, all procedures defined in EN 300 444 [12] GAP are applicable to New Generation DECT 
wideband speech. Therefore the present document can be considered an extension of GAP. 

7.3 New Generation DECT; part 1 : Wideband Speech 
procedures 

The present document is defined as an extension of New Generation DECT; part 1: Wideband Speech [21]. 

Unless otherwise noted, all procedures defined in TS 102 527-1 [21] (New Generation DECT; part 1: Wideband 
Speech) are automatically applicable to New Generation DECT; part 3: Extended Wideband Speech Services. 

Clauses 7.4 to 7.10 describe the additional procedures specific for New Generation DECT; part 3: Extended wideband 
speech services. 

7.3.1 Implementation examples of part 1 : Wideband Speech specific 
procedures 

For detailed examples of Wideband speech specific procedures, please refer to the informative annex D of 
TS 102 527-1 [21]. 
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7.4 Network (NWK) layer procedures specific to part 3 



This clause specifies the additional NWK layer procedures, messages and information elements required in New 
Generation DECT Extended Wideband Speech Services not described in TS 102 527-1 [21] or in EN 300 444 [12] 
(GAP), or incorporating modifications to the description given in these specifications. 

This profile does not prevent any PT or FT from transmitting or receiving and processing any other NWK layer 
message or information element not specified in the profile. A PT or FT receiving an unsupported NWK layer message 
or information element, which it does not recognize, shall ignore it, as specified in EN 300 175-5 [5], clause 17. 



7.4.1 Generic events notification 



7.4.1.1 General 

Equipment supporting New Generation DECT wideband voice shall support the generic events notifications as 
described in this clause. 

Generic events notifications are based on CISS {FACILITY} messages, which contain the information element 
«Events Notification», sent in the direction FT => PT. 

For the purpose of transmitting the { FACILITY } message containing the «Events Notification» information element 
to the PT, the FT shall either: 

• use any already established link used by any Connection Oriented service (such as voice, data or service call), 
if existing; or 

• if there is no existing call at the time of sending the {FACILITY} message, use the CLSS procedure as defined 
in clause 10.4.2.3 of EN 300 175-5 [5]: 

The FT shall initiate indirect link establishment as defined in clause 7.3.8 of TS 102 527-1 [21] "Indirect 
FT initiated link establishment" procedure. The short and the full format with IPUI are allowed in the 
paging messages. The LCE header shall be set to either; the "000" value (indicating "no U-plane") or to 
the "100" value (indicating "General code for voice service"). 

Full slot and long slot (j=640) are allowed as slot type. The chosen slot type (long or full) is decided by 
the initiating party (FT). 

Whatever the {FACILITY} transport mode (CLSS procedure or re-use of already established link), the {FACILITY} 
message shall be used with dummy transaction identifier value 6 and the protocol discriminator CISS. 

Direct FP initiated link establishment is out of the scope of the present document. 

The following requirements apply for the FP and the PP: 

• The FP shall send the "Event type" and "Event sub type" arguments to indicate the kind of event. 

• The PP shall support the "Event multiplicity" argument which should be used to indicate how many 
unconsulted events of the specific type are waiting, regardless of any previous notification. The PP shall be 
capable of handling values up to 16 383. The PP shall ignore events of unknown types or sub-types. 

• It is the responsibility of the FP to ensure that Event status information within the PP is up to date. 
The «CALL-INFORMATION» IE may be present in a notification and is used for indicating: 

• the line the notification is relating to (if any); or 

• that the notification is relating to all lines (using "All lines" subtype). 

For notifications relating to a set of lines (but not all), the «CALL-INFORMATION» IE shall contain the list of 
these lines. 

NOTE 1 : Notification relating to a set of lines (but not all) are not used in the present document and are for future 
use. 
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Optionally more than one event notification can be included by using the extension bit. In that case: 

• If a «CALL-INFORMATION» IE is used, each of the notifications sent together shall relate to the specified 
line, or to 'All lines', or to a set of lines, as above. 

• If no «CALL-INFORMATION» IE is used, each of the notifications sent together is not related to any line. 



Table 13: Values used within {FACILITY} message to convey Lineld in notification 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Call information» 








<ldentifier type> 





Line identifier 


<ldentifier subtype> 


'00'H, 
'03'H, 
'04'H 


'Line identifier for external call', 
'Relating to', 
or 'All lines' 


<ldentifier value> 


All, except 127 


The line identifier value itself if 
present (e.g. it is absent if 'All lines' 
subtype is used) 

Value 'None' (127) cannot be used 



Notification of an event shall be sent only to relevant PPs. Depending on the event nature, receiving the notification 
may be relevant for one or more PPs, or for one or more lines: 

If not related to a line but related to one or more PPs, the notification shall be sent by the FP to the concerned 
PP (or PPs) without specifying any line identifier (i.e. without any «CALL-INFORMATION» information 
element). 

EXAMPLE 1 : This is the case for the Internal Names List (see clause 7.4. 10.2) and the DECT System Settings 
List change notifications if implemented. 

If related to a line, the notification shall be sent by the FP to all registered PPs that are attached to this line with 
a line identifier in a «CALL-INFORMATION» to convey the line concerned by this notification (using 
"Line identifier for external call" or "Relating to" subtype). The FP shall use the "Attached handsets" line 
setting to determine these PPs. 

NOTE 2: A PP may be attached to several lines. 

EXAMPLE 2: This is the case for the "Voice message waiting notification" (see clause 7.4.1.2), or the "Missed 
calls notification" (see clause 7.4.1.3). 

If related to all lines, the notification shall be sent to all registered PPs, with a line identifier subtype set to "All 
lines" in a «C ALL-INFORM ATION» information element. 

EXAMPLE 3: This may be the case for the Contact List, if notification is implemented and the line identifier of 
the modified entry is "All lines" subtype. 

7.4.1 .2 Voice Message waiting notification 

Upon reception of a voice message waiting indication (MWI) from the network on a dedicated line, the FP shall send to 
any PP attached to this line, a voice message waiting notification using the generic events notification. 

NOTE 1 : The FP is aware of the attached handsets to a line thanks to the Line Settings List/attached handsets field. 

Voice message waiting notification shall always be sent with a line identifier using subtype Line identifier for external 
call'. 

«Events notification» information element shall be filled with the values specified in table 14. 
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Table 14: Values used within {FACILITY} message for voice message waiting indication activation 



Information element 


FipIH within thp information 
riciu vv iuiiii ii i c iiiiuiiiidLiuii 

plpmpnt 


OldMUCII U VCIIUCO 

within thp fipld/IE 

Will III 1 III w 1 1^ 1 VI/ 1 1— 


Nnrmativp aptinn/rrimmpnt 

liUI 1 1 lull VC a\j L 1 \J 1 1/ VsVfl 1 II 1 1 C 1 11 


«Events notification» 








<Event type> 





Message waiting 


<-tvt;iiL ouu lyjjc--* 


■ 


V UIUU 


<Event multiplicity> 


0..127 


Number of messages, for the 
specified line (see note at this table 
and note 2 after the table) 


«Call lnformation» 








<ldentifier type> 





Line identifier 


identifier sub type> 





Line identifier for external call 


<ldentifier value> 


All, except 127 


The line identifier value itself 
Value 'None' (127) cannot be used 


NOTE: 'Event multiplicity' can be extended for values up to 1 6 383. See note 1 at table 39. 



Upon reception of a { FACILITY } message with a content as defined in table 14, the PP shall indicate the Voice MWI 
status to the receiving user. 

Voice message waiting deactivation notification 

As soon as the number of messages for a given line is '0', the FP shall then send a 'Voice message waiting notification' 
to all PPs attached to that line, with an <Event multiplicity> field set to '0'. 

NOTE 2: The meaning of this number is network dependent; e.g. it may be the total number of messages in the 
voicemail box, or the total number of unread messages in the voicemail box only. 

NOTE 3: This notification allows the PP to give a hint to the user that the voicemail box does no longer need to be 
consulted for the specified line. A PP attached to several lines could wait until it receives such a 
notification for all lines it is attached to, before it gives a hint to the user (e.g. switch off an MWI-LED). 

Voice message waiting notification update 

A Voice message waiting activation/deactivation notification shall be sent by the FP after successful location 
registration of the PP, once for each line the PP is attached to (one {FACILITY} message per line the PP is attached to). 

NOTE 4: A location registration request ({LOCATE-REQUEST} message is sent by the PP at least when the 

handset is switched on. A location registration request could be sent by the PP when it goes back in range 
(after it got out of range) in order to inform the FP that it may have lost some notifications (see 
clause 7.4.18). 



7.4.1 .3 Missed call notification 

A 'missed call notification' is sent by the FP each time any event modifies the Missed Calls List. This most notably 
happens when an external incoming call has not been answered by any of the PPs (an entry was added to the Missed 
Calls List). 

The present procedure also specifies the sending of list change indications for the Missed Calls List (see 'Simultaneous 
'list change indication' clause below). 

Line identifier. An event modifying the Missed Calls List always occurs on, or concern, one of the lines of the system. 
The notification is sent to all PPs attached to that line, and only to them. A 'missed call notification' shall contain a line 
identifier, specified in a «CALL INFORMATION» IE, using the line id subtype Line identifier for external call'. 

Line specific event multiplicity. The <event multiplicity> field of the 'missed call notification' shall contain the 
number of 'unread' missed call entries in the Missed Calls List for the specified line, at the time the notification is sent. 

NOTE 1: An 'unread' missed call entry is an entry with 'Read status' field set. It corresponds either to a missed call 
that was just added to the Missed Calls List, or to a missed call that was already in the Missed Calls List 
but remained 'unread'. 

NOTE 2: The 'Number of calls' field of the Missed Calls List (see clauses 7.4.10.5.1.8 and 7.4.10.5.3) is not taken 
into account when computing the <event multiplicity> field: only entries are computed. 
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Simultaneous 'list change indication'. A 'list change indication' for the Missed Calls List shall be sent together with 
the 'missed call notification', in the same «Events notification» IE. 

Conversely, a 'list change indication' for the Missed Calls List shall never be sent alone, but always along with a 'missed 
call notification'. 

NOTE 3: Missed call subtype '02'H (see EN 300 175-5 [5], clause 7.7.55) is used to indicate that there is not 

actually any new missed call: in that case, the purpose of the accompanying 'missed call notification' is to 
possibly update the number of 'unread' missed calls on PP side. 

EXAMPLE 1 : If a 'list change indication' is sent following the reading of an entry by one of the PPs (entry read 
status modified) the accompanying missed call notification indicates the new number of 'unread' 
entries. 

EXAMPLE 2: If a 'list change indication' is sent following the deletion of a 'read' entry the accompanying missed 
call notification indicates the same number of 'unread' entries (i.e. serves no purpose). 

The <event multiplicity> field of the 'list change indication' shall contain the total number of entries in the Missed Calls 
List for the specified line, at the time the notification is sent ('unread' plus 'read' missed calls). 

Events triggering the notifications. The following event types shall trigger a 'missed call notification' together with a 
'list change indication' from the FP. For each event type, the line to specify and the set of PPs receiving the notification 
(targeted PP or PPs) are indicated. 

• A new external missed call just arrived (entry added). A 'missed call notification' shall be sent immediately 
after a new external call is missed and has been added to the Missed Calls List. 

Specified line: Line where the missed call occurred. 

Targeted PPs: all PPs attached to the line where the missed call occurred. 

The missed call subtype used shall be '01'H ("A new external missed call just arrived"). 

NOTE 4: Only external missed incoming calls should be added to the Missed Calls List and notified by the FP. 

NOTE 5: When receiving missed call subtype '01'H, the PP should give a hint to the user that the Missed Calls List 
should be consulted (e.g. switching on a dedicated LED). 

NOTE 6: The PP should remove the hint when it received an event multiplicity of '0' for each of the lines it is 
attached to. Additionally, the PP could also do so after having consulted the list. 

• Entry modified or deleted (especially: entry 'read'). A 'missed call notification' (see above) shall be sent as 
soon as an entry in the Missed Calls List is modified (especially: 'read', see clause 7.4.10.5.1.5 for the 
definition of a 'read' entry), or deleted. 

Specified line: Line of the entry that was read or deleted. 

Targeted PPs: All PPs attached to the specified line. 

The missed call subtype used shall be '02'H ("No new missed call arrived, but the number of 'unread' 
external missed voice call has - or may have - changed"). 

NOTE 7: The 'missed call subtype' '01'H (A new missed call just arrived') could however be used if the 'base reset' 
is coincidental with the arrival of a brand new missed call, to avoid sending two notifications. 

• Location registration: A 'missed call notification' shall be sent after location registration, once for each line 
the PP is attached to (1 FACILITY message per line the PP is attached to). 

Specified line: Line for which the notification is sent (once for each line the PP is attached to). 

Targeted PP: The PP performing location registration (and only this PP). 

The missed call subtype used shall be '02'H. 
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NOTE 8: A location registration request ({LOCATE-REQUEST} message) is sent by the PP at least when the 

handset is switched on. A location registration request could be sent by the PP when it goes back in range 
(after it got out of range) in order to inform the FP that it may have lost some notifications(see 
clause 7.4.18). 

NOTE 9: The 'missed call subtype' '01'H (A new missed call just arrived') could however be used if the 'location 

registration' is coincidental with the arrival of a brand new missed call, to avoid sending two notifications. 
But subtype '01 'H cannot be used in order to inform the PP of a missed call that arrived when it was 
possibly out of range and that it may have lost (subtype '01'H can only be used at the time when the new 
missed call arrives, and the notification cannot be repeated). 

Almost simultaneous events. Several events concerning the Missed Calls List occurring almost simultaneously may be 
the subject of a single notification, provided the following rules are respected: 

all events notified together shall occur on, or concern, the same line; 

the events notified together may be of the same type, or of different types (e.g. one entry added for a new missed call, 
another entry modified or deleted); 

the common notification shall use missed call subtype '01'H if (and only if) at least one of the events notified together is 
of type A new external missed call just arrived (entry added)', 

the notified numbers correspond to the state of the Missed Calls List after all the events notified together occurred. 

NOTE 10: Examples of use of these rules are provided in clause C.2.6. 
« Events notification» information element shall be filled with the values given in table 15. 



Table 15: Values used within {FACILITY} message for missed call notification 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 








<Event type> 


1 


Missed call 


<Event sub type> 


1 


A new external missed voice call just 
arrived 


<Event multiplicity 


0...127 


Number of new missed calls in the 
Missed Calls List for the specified 
line (see note 1) 


<Event type> 


3 


List change indication 


<Event sub type> 


1 


Missed Calls List 


<Event multiplicity 


All 


Total number of elements in the list 
for the specified line 


«Call lnformation» 






(see note 2) 


identifier type> 





Line identifier 


identifier sub type> 





Line identifier for external call 


identifier value> 


All 


The line identifier value itself 


NOTE 1 : 'Event multiplicity' can be extended for values up to 16 383. See note 1 at table 39. 
NOTE 2: The «Call information» Information Element is only present if the call is external. 



Upon reception of a {FACILITY} message with a content as defined in table 15, the PP shall indicate the missed call to 
the receiving user. The PP may use the previous calling party information provided with the last incoming call 
presentation. 

After user intervention the PP shall access the Missed Calls List via the list access "Read entries" command (see 
clause 7.4.10.4.3.1) feature. 

7.4.1 .4 List change notification 

See "List access service", list change notification procedure (see clause 7.4.10.2) for the detailed behaviour. 



ETSI 



53 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



7.4.2 Date and Time synchronization 

Equipment supporting New Generation DECT wideband voice shall support the "Date and Time synchronization" 
feature as described in the present clause. 

The DECT entity shall use an already established link for the purpose of transmitting the {FACILITY} message 
containing the «TIME-DATE» information element to the peer entity. It is the responsibility of the entity to ensure 
that time and date information within the peer entity is up to date. 

If there is no existing connection when sending the {FACILITY} message, the CLSS procedure may be used as defined 
in clause 10.4.2.3 of EN 300 175-5 [5] with the «TIME-DATE» information element in the {FACILITY} message. 

Whatever the {FACILITY} transport mode (CLSS procedure or re-use of already established link), the {FACILITY} 
message shall be used with dummy transaction identifier value 6 and the protocol discriminator CISS. 

For the values used in « TIME-DATE» information element see table 16. 



Table 16: Values used within {FACILITY} message for date and time synchronization 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Time-Date» 










<Coding> 


1 1 B 


1 1 Time and Date 




<lnterpretation> 





The current time/date 




<Time/date> 


All 





Additionally, the entity which is sending the {FACILITY} message should correctly set the <Time Zone> field of the 
«TIME-DATE» IE (i.e. GMT, GMT+lh...). If this information is not available from the entity, the <Time Zone> 
field shall be set to null value. This may be the case for a FP when the information is not provided by the network. 

Upon reception of a {FACILITY} message with a content as defined in table 16, the peer entity shall set its time and 
date information to the received one. The date and time on FP side is called "DECT system date and time" in the 
following text. 

The FP and PP shall both support the "FT initiated Date and Time synchronization" procedure of clause 7.4.2.1, for 
synchronizing all PPs with the DECT system date and time. 

The PP should support and the FP shall support the "PT initiated Date and Time synchronization" procedure of 
clause 7.4.2.2. If used by the PP, the FP should not use clause 7.4.2.1 at the same time with the same PP especially 
when using the date and time from the network. 

The present procedure (see clause 7.4.2) shall be consistent with the "Clock master" setting (see clause 7.4.1 1.3.2) of 
the DECT System Settings List (see clause 7.4.11.3), "List access service", feature [NG1.N.16]. 

• If the "Clock master" field is equal to "FP", PPs shall not use the "PT initiated Date and Time synchronization" 
procedure. The FP may set the DECT system date and time as received from the network (e.g. received upon 
network incoming call, or through NTP), or from a dedicated interface (e.g. local or web interface). 

• If the "Clock master" field is equal to "PP": a PP shall be able to define the DECT system date and time on the 
FP, using procedure "PT initiated Date and Time synchronization" of clause 7.4.2.2. The FP shall ignore any 
date and time received by any other means (e.g. received from the network). 

In both cases, the FP shall use procedure "FT initiated Date and Time synchronization" of clause 7.4.2.1 to update the 
date and time of all (other) registered handsets. 
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7.4.2.1 FT initiated Date and Time synchronization 

The present procedure shall be used by the FP in order to update the PP date and time and synchronize it with the DECT 
system date and time. The DECT system date and time could have been provided by the network, or by one of the PPs 
using procedure "PT initiated Date and Time synchronization" of clause 7.4.2.2. 

NOTE: When the "Clock master" setting is implemented, the DECT system date and time origin is restricted. 
However a PP should never ignore the FP notification, even if the "Clock master" field is set to PP, 
because the DECT system date and time may have been set by another PP. 

If link is not available, the FP shall initiate indirect link establishment as defined in clause 7.3.8 of TS 102 527-1 [21] 
"Indirect FT initiated link establishment" procedure. The short format or the full format paging messages with 
corresponding slot types shall be used as for a regular incoming voice call. The LCE header shall be set to the "000" 
value (indicating "no U-plane") or to the "100" value (indicating "General code for voice service"). Full slot and long 
slot (j=640) are allowed as slot type. The chosen slot type (long or full) is decided by the initiating party (FT). 

PP FP 

FACILITY 

< 

«TIME-DATE» 



Figure 1 : FT initiated Date and time synchronization 
7.4.2.2 PT initiated Date and Time synchronization 

In some cases (e.g. if the date and time are not provided by the network or erroneous), the DECT system date and time 
may be provided by one of the PPs, using the present procedure. 

When the "Clock master" field is equal to "PP", the DECT system date and time shall only be provided by one of the 
PPs using the present procedure. 

If link is not available, the PP shall initiate direct link establishment as defined in clause 8.36 of EN 300 444 [12] 
"Direct PT initiated link establishment" procedure. Full slot and long slot (j=640) are allowed as slot type. The chosen 
slot type (long or full) is decided by the initiating party (PT). 

The FP shall check the «Portable Identity» IE sent by the PP in the {FACILITY} message. If the date and time is 
sent by an unidentified PP, the FP shall ignore the time and date. The procedure "FT initiated Date and Time 
synchronization" of clause 7.4.2.1 may be used subsequently, in order to transfer the updated date and time to all other 
registered PPs. 

PP FP 

FACILITY 



«Portable ldentity» «TIME-DATE» 



Figure 2: PT initiated Date and time synchronization 

7.4.3 Handling of parallel calls 
7.4.3.1 Parallel call common requirements 

Procedures in clause 7.4.3 apply to DECT systems allowing to handle several simultaneous calls, and offer a common 
handling of them in various situations (PSTN double calls, VoIP multiple calls on a single line, as well as parallel call 
situations occurring in a multiple line DECT system). Clause 7.4.3 also includes related procedures (for "Call transfer", 
"Call intrusion" and "3-party conference with established internal and/or external calls"). 
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The "Parallel call" feature is a prerequisite feature including high level procedures and requirements. Clauses "Common 
parallel call procedures", "Call transfer", "Call intrusion" and "3-party conference with established internal and/or 
external calls", are all handled here because they imply implementation of the "Parallel call" feature, but are however 
handled as separate features. 

In all parallel call scenarios there shall always be only one link between FP and PP, with one U-Plane and one call 
control instance. 

7.4.3.2 Control messages 

The procedure relates to DECT systems allowing to handle several simultaneous calls, and offers a common handling of 
them in various situations (PSTN double calls, VoIP multiple calls on a single line, as well as parallel call situations 
occurring in a multiple line DECT system). 

The following control codes shall be transmitted as keypad information in {CC-INFO} (or {CC-SETUP} if explicitly 
noted) messages and shall trigger the corresponding actions in the FP according to table 17. 
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Table 17: Control messages for control of parallel calls 



Procedure 


Control message 


Direction 


PP Status 


FP status 


Outgoing parallel call initiation (internal) 


17H + number 

17H + '*' (see note 1) 


PP to FP 


M 


M 


Outgoing parallel call initiation (external) 


1 C1 5H + number (see note 2) 


PP to FP 


M 


Ivl 


Call waiting indication (external or internal) 


Call status CS call setup + IE 
«SIGNAL = 'call waiting tone' 
= 07H» + IE «CLIP» (see 
notes 3 and 8) 


FP to PP 


M 


Ivl 


Intrusion call request indication (only 
internal) 


Call status "CS conference 
connect + lb «bi(jiNAL = 
iniercepi lone uin = u<iri>> 
(see note 8) 


FP to PP 


o 


C1 702 


Call toggle request (external or internal) 


\ On ol n 


pp t/i CP 

rr 10 rr 


IVI 


IVI 


3-party conference call request (external or 
internal) 


1CH 32H 


PP to FP 





C1703 


Call release (of the indicated call) 


1CH33H 


PP to FP 


M 


Ivl 


Call transfer request (external or internal) 


J P| 1 O A II 

1CH 34H j 


PP to FP 


i\ /i 
Ivl 


h n 

M 


Call waiting acceptance 


1CH 35H 


PP to FP 


M 


M 


Call waiting rejection 


1CH 36H 


PP to FP 


M 


M 


Active call release with replacement (from 
PP to FP) 


1CH 38H 


PP to FP 


O 


M 


Negative acknowledgement 


Confirmed call status + IE 
«SIGNAL, 09H = negative 
acknowledgement tone» (see 
note 8) 


FP to PP 


M 


M 


Explicit call intrusion 


1CH 40H in {CC-SETUP} + 
targeted terminal identifier 
number (handset intrusion) or 
targeted line id (line intrusion) 


PP to FP 


O 


C1702 


Putting a call on-hold 


1CH 41H 


PP to FP 


O 


Ivl 


Resuming a call put on-hold (see note 9) 


1CH42H 


PP to FP 


M 


Ivl 


Call interception request from HPP (or PP) 
(see note 7) 


1CH 50H in {CC-SETUP} 


PP to FP 


C1701 


M 


C1 701 : If the PT is a headset PP THEN "M" ELSE "0". 

C1702: If FP implements intrusion call feature (NG1 .N10) THEN "M" ELSE minimum requirement of "negative 
acknowledgement" with call status reason 'control code not supported' (see clause 7.4.3.4). 

C1 703: If FP implements conference call feature (NG1 .N9) THEN "M" ELSE minimum requirement of "negative 
acknowledgement" with call status reason 'control code not supported' (see clause 7.4.3.4). 


NOTE 1 : The '*' is used to call all the registered handsets (except the initiator) and the FP when capable of; this function 
is also called "internal general call" as defined in Generic Access Profile (GAP) 
EN 300 444 [12]. It may be also used when only two PPs are registered (this allow to omit the terminal 
number). 

NOTE 2: This value is purposely distinct from '1 5'H value, although it is used here in a similar context. Use of 31 H, 32H, 
33H, 35H, etc., as number after 15H may have a specific meaning for the network. For backward compatibility 
reasons, the FP may have to interpret these codes as control messages or send them transparently to the 
network. 

NOTE 3: Numbering plan id field of CLIP IE is set to "private numbering plan" for internal calls, any other type for 

external calls (as specified in TS 102 527-1 [21]). 
NOTE 4: The definition of the new CO-control code 1 C is proposed for use as described in table 1 7. 
NOTE 5: The new DECT codes may need a translation into network control messages on FP side. These messages 

are network operator dependent. 
NOTE 6: Network control messages may be sent directly by the user as keypad information. The FP should send them 

transparently to the network. 

NOTE 7: "Call interception" means that a PP intercepts a call initiated (i.e. being setup or in active state) by another PP. 

The intercepting PP is in principle a headset PP but could be any standard PP (see clause 7.4.16.2). This 

control code will be transmitted as keypad information in a {CC-SETUP} message. 
NOTE 8: See clause 7.4.6.4 for the definition of call statuses. Presence of «Signal» IE depends on the "Tones 

provision" feature. See clause 7.4.3.4 for more details on the negative acknowledgement. 
NOTE 9: "Resuming a call put on hold" (1 C 42H) is mandatory for PPs since it may be needed by the call release 

procedure (see clause 7.4.3.5.4). The control code may be sent after interaction with the user, or automatically 

by the PP. 
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7.4.3.3 Codec change for parallel calls 

If the parallel calls use different codecs the standard codec change procedure shall be used (see TS 102 527-1 [21], 
clause 7.3.4 and annex D). 



PP FP 



Call established 




CC-INFO 



«MULTI-KEYPAD, 17H/15H» 

CC-INFO 
«MULTI-KEYPAD, number digits» 

CC-INFO 
«MULTI-KEYPAD, number digits» 

CC-SERVICE-CHANGE 

«CODEC-LIST» 
CC-SERVICE_ACCEPT 

IWU-INFO 
«CODEC-LIST» 

IWU-INFO 
«CODEC-LIST» 



Figure 3: Codec change procedure: example for outgoing call initiation 
7.4.3.4 Sending negative acknowledgement 

When the FP fails to fulfil a service requested by the PP, the FP shall reply to the PP with the current call status of the 
call targeted by the request, and with an appropriate call status reason (e.g. 'control code failed'), using procedure "Call 
status indication to the handset (FP to PP)" of clause 7.4.6.4. 

NOTE 1 : The call targeted by the request is defined by the call id included in the request. The re-sending of the 

current call status of this call is used to confirm that the service request was ineffective and did not result 
in a call status change. 

NOTE 2: The call status reason to be used is indicated when the present procedure is referred to in other 
procedures. 

The FP shall additionally send a 'negative acknowledgment tone' to the PP in the same or in a subsequent {CC-INFO} 
message. The "Tones provision" feature describes the method that shall be used by the FP and PP to support the tone. 

A possible cause of failure may be unsuccessful interaction of the FP with the network. In that case the FP shall use the 
present procedure, using the call status reason 'control code failed'. 

Table 17a describes the main cases where a negative acknowledgement shall be answered by the FP with 'control code 
failed' reason. For each case, either a negative acknowledgement is systematically sent (call status of the targeted call 
not consistent with the request type), or sent only if the request fails (the request is semantically correct but happens to 
fail when processed by the FP or the network). 
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Table 17a: Use of negative acknowledgement 



Use of negative 
aCKnowieuyciiieni 




Call status of targeted call 

This call status is repeated in the negative acknowledgement 


Request type (clause title) 


Clause 
nurnDer 


CS call connect 


CS call hold 


CS call setup 


CS idle 

(see note) 


Call toggle 


7.4.3.5.3 


negative ack 


negative ack 
if failure 


negative ack 


negative ack 


Call release 


7.4.3.5.4 


negative ack 
if failure 


negative ack 
if failure 


negative ack 


negative ack 


Call waiting acceptance 


7.4.3.5.6 


negative ack 


negative ack 


negative ack 
if failure 


negative ack 


Call waiting rejection 


7.4.3.5.7 


negative ack 


negative ack 


negative ack 
if failure 


negative ack 


Putting a call on hold 


7.4.3.5.8 


negative ack 
if failure 


negative ack 


negative ack 


negative ack 


Resuming a call put on hold 


7.4.3.5.9 


negative ack 


negative ack 
if failure 


negative ack 


negative ack 


Active call release with 
replacement 


7.4.3.5.12 


negative ack 


negative ack 
if failure 


negative ack 
if failure 


negative ack 


NOTE: This case corresponds to a situation where a PP would make a request on an invalid call id (call in 'CS idle' 
status). 



NOTE 3: In the special case where the requested service cannot be fulfilled because it would exceed the DECT 

system or line capacity, the "Busy system or line notification" procedure of clause 7.4.8.3 is used instead. 
The main identified use case is in the context of multiple call lines (clause 7.4.8) but other parallel call 
use cases are relevant (e.g. in the context of a multiple lines DECT system). See also NG1.N.6 in 
clause 6.10. 

As a special case, when the FP does not support a feature, but however receives from a PP a request for initiating that 
feature with the corresponding control code, the FP shall use the present procedure, using the call status reason 'control 
code not supported'. 

NOTE 4: As stated above, use of the present procedure includes re-sending of the current call status before the PP 
request was sent, together with the call status reason. 

EXAMPLE: The optional features 'intrusion call' (NG1 .N. 10), 3PTY conference call (NG1.N.9), and call 
deflection (NG1.N.1 1) are examples of features that the FP may not support. 

7.4.3.5 Common parallel call procedures (external or internal) 

This clause details the procedures of a feature entitled "Common parallel call procedures (external or internal)". This 
feature is a set of common procedures for handling PSTN double calls, VoIP multiple calls on a single line, as well as 
parallel call situations occurring in a multiple line DECT system (and especially for PPs attached to multiple lines in 
such a system). 

These procedures apply to the FP and a PP already involved in at least one call on a line in a DECT system. If the 
"Multiple call" feature is implemented on a line, this line may be configured in "single call" mode, or in "multiple call" 
mode (see clause 3.1). 

Implementation of the "Parallel calls" feature is a pre-requisite on PP and FP sides for implementation of the "Common 
parallel call procedures (external or internal)" feature. 

Implementation of the "Call Identification" feature on PP side and on FP side is a prerequisite for implementation of the 
"Common parallel call procedures (external or internal)" feature on a DECT system. 

Implementation of the "Line Identification" feature on PP side and on FP side is a prerequisite for implementation of the 
"Common parallel call procedures (external or internal)" feature on a DECT system. 

A PP implementing the "Common parallel call procedures (external or internal)" shall be able to support at least two 
simultaneous call contexts. 

Implementation of the "Common parallel call procedures" feature is itself a prerequisite for the implementation of the 
"Multiple calls" feature, or of the "Multiple lines" feature on a DECT system. 
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7.4.3.5.1 Outgoing parallel call initiation (external or internal) 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

External outgoing parallel call initiation. The initiation of an external outgoing parallel call shall be done by sending 
the control code 1CH, followed by the register recall (15H) keypad information in a « MULTI-KEYPAD» IE in a 
{CC-INFO} message. In the same or other {CC-INFO} message(s), one or more further keypad information containing 
the decimal coded digits of the external number shall follow. 

Internal outgoing parallel call initiation. The initiation of an internal outgoing parallel call shall be done: 

• either by sending the internal call ('17'H) keypad information in a « MULTI-KEYPAD» IE in a first 
{CC-INFO} message and the decimal coded digits of the internal number, in a « MULTI-KEYPAD» IE in 
a second {CC-INFO}message; or 

• by sending the internal call ('17'H) keypad information together with the digits in a « MULTI-KEYPAD» 
IE in one single {CC-INFO} message. 

For an internal parallel call, the number shall be the terminal id number of the targeted PP, or '*' in case of "internal 
general call". '*' may also be used when only two PPs are registered (this allows to omit the terminal number). The 
number of registered PPs is available from the Internal Names List. 

An outgoing parallel call initiation (external or internal) from the PP implicitly requests that the active call (if any) be 
put on hold by the FP (especially if the parallel call is external). 

NOTE 2: If the parallel call is internal and there is an active call on the PP, the FP does not need to actually put the 
active call on hold toward the remote party but could just simulate it (e.g. by playing an audio film in the 
FP toward the remote party). 

NOTE 3: There may be no active call on the PP when the procedure is used. For example, this allows to put the 
active call on-hold in a first separate step (using clause 7.4.3.5.8, 'Putting a call on-hold'), and then to 
initiate an outgoing parallel call in a second step. 

If there is an active call on the PP, the FP shall put this call on-hold in the first message back to the PP and then proceed 
further with the parallel call. 

After the PP has sent a first {CC-INFO}message, and if the PP intends to use several {CC-INFO} messages in order to 
complete the outgoing parallel call initiation, the PP shall wait until it receives the call id assigned by the FP before 
sending subsequent messages, and shall include the received call id in these messages. 

If the line or the FP cannot support the additional call: 

• the FP shall use the "Busy system or line notification" procedure of clause 7.4.8.3 (instead of returning a "CS 
call hold"), that is: 

call status 'CS call disconnecting' sent along with the appropriate call status reason (e.g. 'line in use' or 
'system busy'); 

«CALL INFORMATION» IE sent with call status 'CS idle' in order to free the call id. 
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PP 



FP 



Outgoing 
parallel call 
initiation 





Ongoing call (external or internal), call id = 1 



CC-INFO 




« MULTI-KEYPAD, < Keypad info = '1C15'H / '17' H > » 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 



The FP assigns a call identifier: 

For NG-DECT Part 3 PPs 
only: 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 
id type/subtype = 'Call status', value = 'CS call setup ack' > 




The PP selects the line to use: 



CC-INFO 



« CALL-INFORMATION, 
Line selected for the call by a Part 3 < id type = 'Line identifier', 
PP using the CALL-INFO method subtype = 'external call', 

(external call only) value = 'u' > 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 

OR » 

Line selected for the call by a GAP, 
or Part 1 PP using the KEYPAD « MULTI-KEYPAD, 
method < Keypad info = '23 3u'H > » 

(external call only) 



FP line confirmation 

For NG-DECT Part 3 PPs 
only: 



CC-INFO 



« CALL-INFORMATION 

< id type = 'Line identifier', subtype = 'external call', value = 'u' > 

< id type = 'Line identifier', subtype = line type information', value = 'xy'B > 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION 

< id type/subytpe = 'Call identifier', 
value = 'assigned call id' > 



Figure 4: Outgoing parallel call initiation request with line selection by the PP 

Line selection: For sending to the FP the line identifier selected for the new external call, one of the following methods 
shall be used: 



for Part 3 PPs only, included in a « CALL INFORMATION» information element sent in a {CC-INFO} 

message; or 



for GAP and Part 1 PPs, included in a « MULTI-KEYPAD» IE sent in a {CC-INFO} message. This 
method shall only be used if the line identifier is in the interval 0..9. If this method is used, the line identifier 
information shall consist in the pound key ("#") character ('23'H) followed by the line identifier digit, 
IA5-coded on a single octet. 
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FP line confirmation: For Part 3 PPs, the FP shall confirm the selected line in a {CC-INFO} message sent back to the 
PP, including the line type information for the selected line. 

NOTE 4: Instead of the sequence given above, the PP might also combine '1C15'H / 17'H, line selection and called 
number in two or three messages. In these cases the FP will answer correspondingly in two or more 
messages. See clauses C.3 "Multiple calls diagrams" and C.4 "Parallel call complex or alternative 
diagrams", for more information. 

FP-managed line selection: If the PP uses "FP-managed line selection" (see clause 7.4.5.2.4) for an external call, one 
of the following methods shall be used: 

• for Part 3 PPs only, by using the special line id value 'None' (see clause 3.1). This value shall be sent instead of 
a regular line id, at any possible time and in any possible location for sending a regular line-id. The FP shall 
send back to the PP the line identifier value including the line type information for the selected line for the 
call; 

• for GAP or Part 1 PPs, by having their default behaviour of sending no line identifier, hence implicitly using 
"FP-managed line selection". In front of a GAP or Part 1 PP, a Part 3 FP shall wait for the first keypad 
information received from PP. If this keypad information is different from '23'H ('#' character), the FP shall 
infer that "FP managed line selection" is used, and shall therefore select a line on behalf of the PP. The FP may 
notify back the user of the PP of the used line identifier using a «DISPLAY» information element, but shall 
not use any «CALL-INFORMATION» element toward the PP. 

See figure 5 for detailed sequence flowchart (part 3 PP case). 

Internal call: In case of internal call, no line identifier shall be sent. 



PP 



FP 





<C^^ Ongoing call (external or internal), call id = 1 J^^> 


Outgoing call initiation 




Outgoing 
parallel call 
initiation 


CC-INFO ^ 


« MULTI-KEYPAD, < Keypad info = '1C15'H / '17'H > 




( CC-INFO 




« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 


Call id assignment by the FP 


CC-INFO 




~+ 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 








CC-INFO 


FP-managed line selection: The 

Part 3 PP does not select the line 
to use (uses 'None' subtype). 


« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION 

< id type = 'Line identifier', subtype = 'external call', value = 'None'> 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 

» 


The FP sends the line id: 

also if the PP is attached to 
only one line 

or if there is only one line in 
the system 


CC-INFO 


« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value = 'u' > 

< id type='Line identifier', subtype='line type information', value = 'xy'B> 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 

< id type/subtype = 'Call status', value = 'CS call proc' > 



Figure 5: Outgoing parallel call initiation request with FP-managed line selection 
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The call statuses shall comply with clause 7.4.6.4 provisions. 

The FP may change the audio codec for the parallel call by use of the service change procedure (see clause 7.4.3.3, 
"Codec change for parallel calls"). 

If the parallel call is internal, the FP shall use the GAP "internal call CLIP" and "internal call CNIP" procedures for this 
parallel call (see clause 6.10). 

NOTE 5: In case of internal call, the '*' character can be used as called number, meaning that an 'internal general 
call' is attempted. 

7.4.3.5.2 Call waiting indication (external or internal) 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented and used 
on a line, the line may be configured in "single call" mode, or in "multiple call" mode. 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

NOTE 2: In "single call" mode, PPs not involved in a call do not receive the call waiting indication and do not ring. 
In "multiple call" mode, there may be several PPs already involved in a call and all of them receive the 
call waiting indication; idle PPs receive an incoming call request and ring. 

Call waiting shall be indicated by the FP by sending in a {CC-INFO} message the information element 
«CALL-INFORMATION» with the call status 'CS call setup'. Together with this procedure, the FP shall use the 
"CLIP on call waiting" procedure of clause 7.4.3.5.10. 

Whenever required by the "Tones provision" feature, the FP shall additionally send the «SIGNAL» IE with the value 
'07'H indicating 'call waiting tone on'. 

Whether sent in the same or in different {CC-INFO} messages, the sending of the three involved IEs shall respect the 
following rules: 

• call status in «Call Information» IE shall always be sent in the first used {CC-INFO} message. If the call is 
external, the line identifier (including the 'line type information') shall also be sent in the first used 
{CC-INFO} message, together with the call status; 

• whether sent in the same or different {CC-INFO} messages (including the first one above), the other two 
involved IEs shall always be sent in the following order: «Signal» (if any), «Calling Party Number». 

NOTE 3: These rules are consistent with the order specified in EN 300 175-5 [5], clause 6.3.2.2 for IEs within the 
same {CC-INFO} message. 

Furthermore, as a result of the "Call identification" feature, the FP shall notify the PP of the call identifier used for the 
waiting call on this PP by sending it in a «CALL-INFORMATION» information element included in every 
{CC-INFO} message used (one or two). 

NOTE 4: As described in clause 7.4.6.1, the FP may assign different call ids for the different PPs for an external 
incoming call; this includes 'call waiting' use cases for a line in "multiple call" mode. 

If an internal call is waiting, the information element «Calling Party Number» shall indicate a private numbering 
plan. 
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PP FP 





■<^^^ Ongoing call (external or internal), call id = 1 

Call waiting indication 

CC-INFO 




If required by the "Tones « SIGNAL value = 'call waiting tone' = '07'H » 
provision' feature 


| « CALL-INFORMATION, 


Line on which waiting call < id type = 'Line identifier', subtype = 'external call', value = 'waiting call line id' > 
occurred if external (see note) < id type = 'Line identifier', subtype = 'line type information', value = 'xy'B> 


CW tone 
heard by user 


< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H >, 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 

CC-INFO 


« CALLING PARTY NUMBER, < Calling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 

» 



NOTE: The line identifier indicates to the PP on which line the waiting call occurred and also indicates the 'line 
type information' of this line (if external). 

Figure 6: Call waiting indication 

To accept the waiting call, the "Call waiting acceptance" procedure or the "Call waiting acceptance with active call 
released" procedure shall be used (see clauses 7.4.3.5.6 or 7.4.3.5.12). 

To reject the waiting call, the "Call waiting rejection" procedure shall be used (see clause 7.4.3.5.7). 

If the remote party hangs up before the waiting call has been accepted or rejected, the FP shall send a "CS idle" call 
status to the PP, with the call id of the waiting call. 

7.4.3.5.3 Call toggle (external or internal) 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

If two parallel calls are established, in order to toggle between the calls, the PP shall send a toggle request to the FP 
consisting in the control code 1CH as keypad information in a {CC-INFO} message, followed by 31H. Furthermore, the 
PP shall send the identifier of the call targeted by the toggle in a «CALL-INFORMATION» information element 
included in the same {CC-INFO} message. 

NOTE 2: A PP sends the call identifier of the targeted call, even if it toggles between two calls only. 

The FP may change the codec using the service change procedure (see clause 7.4.3.3, "Codec change for parallel 
calls"). 

The FP shall indicate the result of the toggling by use of call status indications: 

• if the toggle request is successful, the FP shall indicate first call status 'CS call hold' for the previously active 
call, and then 'CS call connect' for the targeted call; 

• if the toggle request is unsuccessful, the FP shall send a negative acknowledgment as described in 

clause 7.4.3.4 (current call status of the targeted call re-sent along with call status reason 'control code failed'). 
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Ongoing calls (external or internal) 
Call id=1 , call status = 'CS call connect' 
C all id=2, call status = 'CS call hold' 

Call toggle request 

CC-INFO 




« MULTI-KEYPAD, info = '1C 31'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'targeted call id' = '02'H> 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call connects 

» 

Figure 7: Call toggle request 



7.4.3.5.4 Call release and call release rejection 

This procedure applies to the FP and a PP already involved in at least two voice calls on a DECT system implementing 
the feature entitled "Common parallel call procedures (external or internal)", and is used by the releasing party (PP or 
FP) in order to release one of these calls. 

This procedure also applies to the FP and a PP already involved in one voice call, and one LiA session at least. 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

NOTE 2: For the relationship between call release and the call id lifecycle, see also clause 7.4.6.1, "Call 
identification general requirements" 

When releasing the last parallel call of the PP (with no existing LiA session): 

• the PP shall not use the current procedure (but use a CC-RELEASE instead); 

• the FP may use it (e.g. send a 'CS idle' before it sends a {CC-RELEASE} to the PP). 

When releasing the last parallel call of the PP and a LiA session is still going on (see clause 7.4.10.6.6): 

• the PP may use the current procedure in order to return to the LiA session; 

• the FP may use it (e.g. if the remote party hangs up). 
If the PP is the releasing party: 

• The procedure shall only apply for an already accepted call. Use of the procedure for a waiting call shall 
trigger a negative acknowledgement from the FP with call status reason 'control code failed' (see also table 17a 
in clause 7.4.3.4, 'Sending negative acknowledgement'). 

NOTE 2a: If the procedure is successful, the call is therefore released for the whole DECT system. 

NOTE 2b:For a waiting call, call waiting rejection (7.4.3.5.7) may be used instead. However the call is still 
presented to the other PPs (if any) after the rejection. 
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• In order to release the call, the PP shall send a 'call release request' to the FP, consisting in control code 1CH 
as keypad information in a {CC-INFO} message, followed by 33H. Additionally, it shall send the identifier of 
the call to be released in a «CALL-INFORMATION» IE included in the same {CC-INFO} message. 

• If the FP can release the call, it shall answer with the call status 'CS idle' and the call identifier of the released 
call. 

• If the released call is the active call, the FP shall NOT automatically switch the speech path to one of the 
remaining parallel calls. The PP shall use the "Resuming a call put on-hold" procedure of clause 7.4.3.5.9 in 
order to indicate to the FP the on-hold call to be resumed. In order to use this procedure, the PP shall first: 

either interact with the user to let him choose the on-hold call to be resumed; 

or automatically select the on-hold call to be resumed. 

NOTE 3: The only difference between the two options from protocol point of view is the delay between the 'CS 
idle' message from the FP, and the following resuming request from the PP. When the second option is 
used, the PP answer is immediate. 

In some cases, when a call release request is sent by the PP, the FP might not be able to fulfil it, for instance when the 
call to be released is external. In that case: 

• The FP shall send a negative acknowledgment as described in clause 7.4.3.4: call status of the call that was to 
be released (e.g. 'CS call connect' if it was the active call, 'CS call hold' if it was a call on-hold) re-sent along 
with call status reason 'control code failed'. 

If the FP is the releasing party, (i.e. as a result of a remote party hangup): 

• The procedure shall apply as soon as a call id has been assigned to the call and sent (in a previous message) to 
the PP. It shall not be used with a newly defined call id (i.e. not yet communicated to the PP). 

NOTE 4a: The procedure may be used for a parallel outgoing call, even before the call is established (see clause 
C.4.1.5). 

NOTE 4b:The procedure may be used for a waiting call, even before the call has been answered (see clause C.3.2). 
If the procedure is successful, the call is only released for the PP (or PPs) receiving 'CS idle'. 

• In order to release the call for a PP, the FP shall send the call status 'CS idle' together with the call identifier of 
the released call. 

• If the released call is the active call, the FP shall NOT switch the speech path automatically. Instead, the user 
should additionally be warned (e.g. through a PP originating display) of the change in order to invite him/her 
to resume one of the on-hold remaining parties. The speech path can be then switched to one of the remaining 
parties using the procedure "Resuming a call put on-hold" of clause 7.4.3.5.9. 

NOTE 5: When the speech path is switched to one remaining party, the PP should update the displayed call 
information to show the active telephone number. 

NOTE 6: When the PP or FP releases the last parallel call, they do not use the current procedure. However, when 
the FP releases the last parallel call, it should still sent a 'CS idle' call status to the PP before the 
{CC-RELEASE} message is used. A {CC-RELEASE} message does not convey any call identifier. 

The FP may change the codec using the service change procedure (see clause 7.4.3.3, "Codec change for parallel 
calls"). 

NOTE 7: To release all parallel calls, the PP may also send a single {CC-RELEASE} to the FP. 
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PP 



FP 



If the PP is the 
releasing party 



Although the released 
call is the active call, 
the FP shall not switch 
the speech path 
automatically to the 
existing on-hold call 




Ongoing calls (external or internal) 
Call id=1 , call status = 'CS call connect' 
Call id=2, call status = 'CS call hold' 



(Successful) Call release request 

CC-INFO 




« MULTI-KEYPAD, info = '1C 33'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'id of call to be released' ='01 'H > 

» 

Call release request 
succeeds 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS idle' > 

» 



Optional user 
interaction for 
choosing the call to be 
resumed 



On-hold call (with call id 2) 
remains on-hold here 



Resuming a call put on-hold (7.4.3.5.9) 

CC-INFO 



« MULTI-KEYPAD, info = '1C 42'H » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'targeted call id' = '02'H > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call connect' > 

» 



Figure 8: Successful call release of the active call (requested by the PP or not) 
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PP 



FP 




Ongoing calls (external or internal) 
Call id=1 , call status = 'CS call connect' 
Call id=2, call status = 'CS call hold' 



Call release request 

CC-INFO 




« MULTI-KEYPAD, info = '1C 33'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'id of call to be released' ='01 'H > 

» 



Negative acknowledgement 

CC-INFO 



Call cannot be 
released 



« CALL-INFORMATION, 
< id type/subtype = 'Call identifier', value = 'id of call to be released' ='01 'H > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call connect' > 

< id type = 'Call status', subtype = 'Call status reason', 

value = 'control code failed' > 



Figure 9: Failing call release request from the PP 

Release of a 3-party conference call 

Additional requirements applying specifically to 3-party conference calls are described in clause 7.4.3.7 (release sub 
sections). 



7.4.3.5.5 



Void 



7.4.3.5.6 



Call waiting acceptance (from PP to FP) 



This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented on a line, 
the line may be configured in "single call" mode, or in "multiple call" mode. 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

If the PP is already involved in a call (active call) and after a call waiting has been indicated, the acceptance of the 
waiting call shall be done by sending the control code 1CH as keypad information in a {CC-INFO} message, followed 
by 35H. Furthermore, the PP shall send the call identifier of the accepted waiting call used for this PP in a 
«CALL-INFORMATION» information element included in the same {CC-INFO} message. 

NOTE 2: As described in clause 7.4.6.1, the FP may assign different call ids for the different PPs for an external 
incoming call; this includes 'call waiting' use cases for a line in "multiple call" mode. 



NOTE 3: The PP sends the call identifier of the waiting call used for this PP, even if there is a single call waiting. 
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The active call shall be automatically put on hold and the waiting call shall become active. 

The FP shall indicate to the accepting PP as a result of the call waiting acceptance: call status 'CS call connect' for the 
waiting call, and 'CS call hold' for the previously active call. 

NOTE 4: If any of these calls is released in the meantime by the remote party, the FP may directly send a "CS idle" 
(or "CS call disconnecting") on the corresponding call id instead. 

In "multiple call" mode, when the PP accepts the waiting call, ongoing procedures for handling the call on other PPs 
(using the present clause, or EN 300 444 [12] (GAP), clause 8.12, "Incoming call request", if it is a first call for the 
concerned PP) shall be terminated. In particular, the FP shall free the call ids used for all other PPs (if different), and 
idle PPs shall stop ringing. If several handsets either pick-up or accept the waiting call, only the first action shall be 
taken into account. The other actions shall be ignored. 

The FP may change the audio codec for the accepted call by use of the service change procedure. 



PP 



FP 



If required by the Tones 
provision' feature 



Line on which waiting call 
occurred if external 
(see notes 4 and 5) 



CW tone 
heard by user 




Ongoing call (external or internal), call id = 1 



CC-INFO 




« SIGNAL value = 'call waiting tone' = '07'H » 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Line identifier', subtype='line type information', 

value = 'xy'B> 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 

Call waiting acceptance 

CC-INFO 



Internal or external 
call waiting from 
'calling number' 



« MULTI-KEYPAD, info = '1C 35'H 
« CALL-INFORMATION, 
< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H> 

» 

CC-INFO 



In multiple call mode, 
other handsets stop 
ringing or receiving the 
CW indication 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call connect' > 



Figure 10: Call waiting acceptance 



NOTE 5: The line identifier indicates to the PP on which line the waiting call occurred and also the 'line type 
information' of this line (if external). 

NOTE 6: Although the 'network delay type' (within the 'line type information') is already sent in the first 

{CC_INFO} message from FP to PP, the PP may wait until the final {CC_INFO} carrying the 'CS call 
connect' call status before actually adapting the acoustics parameters to the announced 'network delay 
type'. 

If the remote party hangs up before the waiting call has been accepted or rejected, the FP shall send a 'CS idle' call 
status to the PP, as defined in clause 7.4.3.5.4, "Call release and call release rejection". 
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7.4.3.5.7 Call waiting rejection (from PP to FP) 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented on a line, 
the line may be configured in "single call" mode, or in "multiple call" mode. 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

If the PP is already involved in a call (active call) and after a call waiting has been indicated, the rejection of the waiting 
call shall be done by sending the control code 1CH as keypad information in a {CC-INFO} message, followed by 36H. 
Furthermore, the PP shall send the call identifier of the rejected waiting call in a «CALL-INFORMATION» 
information element included in the same {CC-INFO} message. 

NOTE 2: The PP sends the call identifier of the waiting call, even if there is a single call waiting. 

The FP shall indicate the result of the call waiting rejection by use of call status indications: 

• if the call waiting rejection is successful, the FP shall indicate call status 'CS idle' for the waiting call; 

• if the call waiting rejection is unsuccessful, the FP shall send a negative acknowledgment as described in 
clause 7.4.3.4 (call status of the waiting call 'CS call setup' re-sent, along with call status reason 'control code 
failed'). 

NOTE 3: This cannot be used to avoid implementation of the procedure. In other words, there is no 
'unimplemented' call status reason. 



PP 



FP 



If required by the Tones 
provision' feature 



Line on which waiting call 
occurred if external 
(see notes 4 and 5) 



CW tone 
heard by user 



for this PP only: 




Ongoing call (external or internal), call id 



CC-INFO 




« SIGNAL value = 'call waiting tone' = '07'H » 

« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Line identifier', subtype='line type information', 
due = 'xy'B> 



< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 

< id type/subtype = 'Call status', value = 'CS call setup' > 



Call waiting rejection 

CC-INFO 



Internal or external 
call waiting from 
'calling number' 



In multiple call mode, 
other handsets continue 



« MULTI-KEYPAD, info = '1C 36'H 
« CALL-INFORMATION, 
< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H> 

» 

CC-INFO 



ringing or receiving the 
CW indication 



« SIGNAL, value = 'Tones off = '3F'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value= 'waiting call id' = '02'H > 

< id type/subtype = 'Call status', value = 'CS idle' > 

» 

Figure 11: Call waiting rejection 

NOTE 4: The line identifier indicates to the PP on which line the waiting call occurred and also the 'line type 
information' of this line (if external). 
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NOTE 5: On a multiple call line configured in "multiple call" mode, "call waiting rejection" does not necessarily 
imply that the call is rejected by the DECT system. 

In "multiple call" mode, when the PP rejects the waiting call, the "Call waiting indication procedure" shall be 
terminated for this PP, but this shall not affect the handling of this call on other handsets: ongoing procedures for 
handling the call on other PPs (using the present clause or EN 300 444 [12] (GAP), clause 8.12, "Incoming call request" 
if it is a first call for the concerned PP) shall not stop. In particular, idle PPs shall not stop ringing. 

If the remote party hangs up before the waiting call has been accepted or rejected, the FP shall send a 'CS idle' call 
status to the PP, as defined in clause 7.4.3.5.4, "Call release and call release rejection". 

7.4.3.5.8 Putting a call on-hold 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

In order to put a call on-hold, the PP shall send the control code 1CH as keypad information in a {CC-INFO} message, 
followed by 41H. Furthermore, the PP shall send the identifier of the call to be put on-hold in a 
«CALL-INFORMATION» information element included in the same {CC-INFO} message. 

NOTE 2: The PP sends the call identifier of the call to be put on hold, although it is always the active call. 

The FP shall indicate the result of the "Putting a call on-hold" procedure by use of a call status indication: 

• if the procedure is successful, the FP shall indicate call status 'CS call hold' for the targeted call; 

• if the procedure is unsuccessful, the FP shall send a negative acknowledgment as described in clause 7.4.3.4 
(call status of the targeted call 'CS call connect' re-sent, along with call status reason 'control code failed'). 

NOTE 3: This cannot be used to avoid implementation of the procedure. In other words, there is no 
'unimplemented' call status reason. 



PP FP 



Ongoing call (external or internal), call id = 1^~~~^^[]^> 

Request for putting a call on-hold 

CC-INFO 


« 


MULTI-KEYPAD, info = '1C 41 'H » 


« 


CALL-INFORMATION, 




< id type/subtype = 'Call identifier', value ='targeted call id' = '01 'H > 




CC-INFO 


« 
» 


CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value ='targeted call id' = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 



Figure 12: Putting a call on hold 



NOTE 4: In the specific case where the call put on-hold is a conference call, the conference (audio path) should 
remain active in the FP for the two other participants. 

NOTE 5: The use case when the user wants to put only one of the participant's call of a conference on hold is not 
described in the present document. 
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7.4.3.5.9 Resuming a call put on-hold 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

In order to resume a call that was put on-hold, the PP shall send the control code 1CH as keypad information in a 
{CC-INFO} message, followed by 42H. Furthermore, the PP shall send the identifier of the call to be resumed in a 
«CALL-INFORMATION» information element included in the same {CC-INFO} message. 

The procedure shall not be used for an existing active call. 

NOTE 2: The PP sends the call identifier of the call to be resumed, even if there is only one call on-hold. 

The FP shall indicate the result of the "Resuming a call put on-hold" procedure by use of a call status indication: 

• if the procedure is successful, the FP shall indicate call status 'CS call connect' for the targeted call; 

• if the procedure is unsuccessful, the FP shall send a negative acknowledgment as described in clause 7.4.3.4 
(call status of the targeted call 'CS call hold' re-sent, along with call status reason 'control code failed'). 




Request for resuming a call put on-hold 

CC-INFO 

« MULTI-KEYPAD, info = '1 C 42'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value ='targeted call id' = '01 'H > 

» 



CC-INFO 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value ='targeted call id' = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call connect' > 

» 



Figure 13: Resuming a call put on hold 

7.4.3.5.10 CLIP on call waiting 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented on a line, 
the line may be configured in "single call" mode, or in "multiple call" mode. 

CLIP on call waiting shall be indicated by the FP to the PP. 

This indication shall be done by sending in one of the {CC-INFO} message used, the «Calling Party Number» IE. 
More specifically, whether sent in the same or in different {CC-INFO} messages, the sending of the three involved IEs 
shall respect the following rules: 

• Call status in «Call Informations IE shall always be sent in the first used {CC-INFO} message. If the call is 
external, the line identifier (including the 'line type information') shall also be sent in the first used 
{CC-INFO} message, together with the call status. 

• Whether sent in the same or different {CC-INFO} messages (including the first one above), the other two 
involved IEs shall always be sent in the following order: «Signal» (if required by the "Tones provision" 
feature),, «Calling Party Number». 
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NOTE: These rules are consistent with the order specified in EN 300 175-5 [5], clause 6.3.2.2 for IEs within the 
same {CC-INFO} message. 

If the waiting call is an internal call, the information element «Calling Party Number» shall indicate a private 
numbering plan. 



PP 



FP 




Ongoing call (external or internal), call id = 1 



CC-INFO 




Line on which waiting call 
occurred if external 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Line identifier', subtype = 'line type information', 
value = 'xy'B> 



CW tone 
heard by user 



< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H >, 

< id type/subtype = 'Call status', value = 'CS call setup' > 



pp_~[.NFO ^ if required by the 'Tones 

provision' feature 



« SIGNAL value = 'call waiting tone' = '07'H » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 

» 

CLIP on call waiting 

CC-INFO 



« CALLING PARTY NUMBER » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 



Figure 14: CLIP on call waiting 



7.4.3.5.1 1 CNIP on call waiting indication 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented on a line, 
the line may be configured in "single call" mode, or in "multiple call" mode. 

CNIP on call waiting shall be indicated by the FP to the PP. 

This indication shall be done by sending, in one of the {CC-INFO} messages used, the «Calling Party Name» IE. 
More specifically, whether sent in the same or in different {CC-INFO} messages, the sending of the four involved IEs 
shall respect the following rules: 

• Call status in «Call Informations IE shall always be sent in the first used {CC-INFO} message. If the call is 
external, the line identifier (including the 'line type information') shall also be sent in the first used 
{CC-INFO} message, together with the call status. 

• Whether sent in the same or different {CC-INFO} messages (including the first one above), the other three 
involved IEs shall always be sent in the following order: «Signal» (if required by the "Tones provision" 
feature), «Calling Party Number», «Calling Party Name». 

NOTE 1: These rules are consistent with the order specified in EN 300 175-5 [5], clause 6.3.2.2 for IEs within the 
same {CC-INFO} message. 
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PP 



FP 




Ongoing call (external or internal), call id = 1 



CC-INFO 




Line on which waiting call 
occurred if external 



CW tone 
heard by user 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Line identifier', subtype = 'line type information', 

value = 'xy'B> 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H >, 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 

pp_"!f^9 lf required by the 'Tones 

provision' feature 
« SIGNAL value = 'call waiting tone' = '07'H » K 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 



« CALLING PARTY NUMBER » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 

» 

CNIP on call waiting 

CC-INFO 



« CALLING PARTY NAME » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 



Figure 15: CNIP on call waiting 



NOTE 2: If both CLIP and CNIP are sent to the PP it is sufficient to display one of them. It is optional to display 
both. 



7.4.3.5.12 Active call release with replacement (from PP to FP) 

The present procedure is primarily intended for backward compatibility of NG-DECT systems with PSTN lines using 
the 'R' key as unique control code. The release of the active call, and the replacement thereof with another call in the 
following two cases: 

1) there is a waiting call, and following the 'active call release request with replacement', the current active call is 
released and replaced with the waiting call: 

in case 1, all requirements of procedure "Call waiting acceptance (from PP to FP)" of clause 7.4.3.5.6 
shall apply, with following modifications: 

■ control code 1CH as keypad information in a {CC-INFO} message, followed by 38H (instead of 
35H) shall be used; 

■ when accepting the waiting call, the active call is released instead of being put on hold. 

there is a call on hold, and following the 'active call release request with replacement, the current active call is released 
and replaced with the call on hold: 

in case 2, all requirements of procedure "Call toggle (external or internal)" of clause 7.4.3.5.3 shall 
apply, with following modifications: 

■ control code 1CH as keypad information in a {CC-INFO} message, followed by 38H (instead of 
31H) shall be used; 
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■ the active call is released instead of being put on hold. 
In both cases, the active call that will be released may be an internal or external call. 

In both cases the used call id is the call id of the call that becomes active after the request is fulfilled. If there is both a 
call waiting and a call on hold the used call id allows to disambiguate the request. 



PP 



If required by the Tones 
provision' feature 



Line on which waiting call 
occurred if external 




Ongoing call (external or internal), call id = 1 



CC-INFO 



« SIGNAL value = 'call waiting tone' = '07'H » 

« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Line identifier', subtype='line type information', 




Internal or external 
call waiting from 
calling number' 



CW tone 
heard by user 



< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H > 

< id type/subtype = 'Call status', value = 'CS call setup' > 



Active call replacement request 

CC-INFO 



« MULTI-KEYPAD, info = '1C 38'H 
« CALL-INFORMATION, 

< id type = 'Call identifier', value = 'waiting call id' = '02'H> 

» 

CC-INFO 



In multiple call mode, 
other handsets stop 
ringing or receiving the 
CW indication 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS idle' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 



< id type/subtype = 'Call status', value = 'CS call connect' > 



» 



Figure 16: Active call replacement with the waiting call 



7.4.3.5.13 Call remote status notification 

This procedure applies to the FP and a PP already involved in a call which is being held by the remote party (external or 
internal). The purpose of the procedure is to improve the PP MMI by informing the user of the remote status of the call. 

Local and remote parties. The local party is the party using the present procedure. The remote party is the other party 
involved in the same call, which may be either internal or external. 
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PP2 



In addition to 
sending the 
call remote 
status, the 
FP may start 
playing an 
audio film 



PP1 



PP1 in internal call with PP2 



FP 



Network 



Call connected (call id 1) 



Call connected (call id 1 




Call on hold with call id 2 (external) 



Call toggle request 

CC-INFO 



« MULTI-KEYPAD, info = '1C 31'H » 

« CALL-INFORMATION, targeted call id = call id 2 

CC-INFO 



« CALL-INFORMATION, call id 1, 'CS call hold' » 
CC-INFO 



« CALL-INFORMATION, call id 1, 'CS call remote hold' » 



CC-INFO 



Between both call remote 
statuses, Call 1 is still 
connected from PP2 

perspective, 
although PP2 user 
cannot speak 



the FP stops 
playing an 
audio film (if 
used) 




« CALL-INFORMATION, call id 2, 'CS call connect' » 

Call toggle request 

CC-INFO 



« MULTI-KEYPAD, info = '1C 31 'H » 

« CALL-INFORMATION, targeted call id = call id 1 

CC-INFO 



« CALL-INFORMATION, call id 2, 'CS call hold' » 
CC-INFO 



« CALL-INFORMATION, call id 1 , 'CS call connect' » 
CC-INFO 



« CALL-INFORMATION, call id 1, 'CS call remote connect' 



Figure 16a: Example of use of call remote statuses 

FP requirements (internal call). If the PP (local party) is involved in an internal call, and the other PP (internal remote 
party) uses a procedure putting this call on hold, the FP shall send a 'CS call remote hold' call status to the PP (local 
party), with the call id of the held call. 

NOTE 1: The possible procedures used by the internal remote party are the following: 

■ Outgoing parallel call initiation (external or internal) of clause 7.4.3.5.1. 

■ Call toggle (external or internal) of clause 7.4.3.5.3. 

Putting a call on hold (7.4.3.5.8). 

If the PP (local party) is involved in an internal call, and the other PP (internal remote party) uses a procedure resuming 
a call put on hold, the FP shall send a 'CS call remote connect' call status to the PP (local party), with the call id of the 
held call 
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NOTE 2: The possible procedures used by the internal remote party are the following: 

■ Call toggle (external or internal) of clause 7.4.3.5.3. 

■ Resuming a call put on hold of clause 7.4.3.5.9. 

■ Active call release with replacement (from PP to FP) of clause 7.4.3.5.12. 

NOTE 3: A PP not implementing the present procedure ignores the 'CS call remote hold' and 'CS call remote 
connect' call statuses. 

NOTE 4: A FP not implementing the present procedure could play an audio film to the local PP for indicating on- 
hold status of the call on remote party side. Such an audio film could also be played in addition to using 
the present procedure. 

FP requirements (external call). If the PP (local party) is involved in an external call, and the system is aware that the 
other party (external remote party) puts the current call on hold, the FP shall send a 'CS call remote hold' call status to 
the PP (local party), with the call id of the held call. 

If the PP (local party) is involved in an external call, and the system is aware that the other party (external remote party) 
resumes a call, the FP shall send a 'CS call remote connect' call status to the PP (local party) with the call id of the 
resumed call. 

EXAMPLE: On a SIP VoIP network, the remote system may inform the local system that the current call is 
being held or resumed by the remote system. 

FP requirements (any call). After sending the 'CS call remote hold' call status to the PP, the FP shall not prevent the 
PP from using a 'common parallel call procedure'. 

PP requirements (any call). The PP should use the received call statuses (CS call remote hold, CS call remote connect) 
in order to inform the user of the call status on the remote party side. 



CS call connect 
CS call remote connect 



(Classical) CS call connect 
Put on hold 



Put on 
hold 



Resume 



CS call connect 
CS call remote hold 



Resume 



Put on 
hold 



CS call hold 
CS call remote connect 



(Classical) CS call hold 
Put on hold 



Resume 



Resume 



CS call hold 
CS call remote hold 



-> 'Local PP' action 
-► 'Remote PP' action 



NOTE: The 'CS call remote connect' and 'CS call remote hold' call statuses concern the remote status of the call 
and are only a way to improve the user interface of the local PP. They do not interfere in any way with the 
local call statuses of the call, as shown in this figure. 

Figure 16b: Call remote statuses do not affect the local (classical) status of the call 



7.4.3.6 Call transfer 

Call transfer is used by the user of a PP involved in two parallel calls to connect the remote parties together before 
ending the existing calls. If one of the remote parties is a handset registered to the same FP, the transfer can be handled 
at FP level; otherwise, the success of the transfer is network dependent. 

Transfer target: The phrase "transfer target" refers to the internal or external party to which the call is transferred. 

Implementation of the "Common parallel calls procedures" feature is a pre-requisite on PP and FP sides for 
implementation of the "Call transfer" feature. 
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The call transfer may be announced or unannounced, depending on when the call transfer control message is sent by the 
PP. 

In order to transfer a call, the PP shall first establish a parallel call with the call transfer target, and then send the control 
code 1CH as keypad information in a {CC-INFO} message, followed by 34H. Furthermore, the PP shall send the 
identifier of the call to be transferred in a «CALL-INFORMATION» information element included in the same 
{CC-INFO} message. 

The FP shall understand a call transfer request as a request for transferring the previously active call to the currently 
active call. 

The call release, using a {CC-RELEASE} message shall be issued by FP. When the transfer target is internal and only 
after the {CC-RELEASE} message has been sent (i.e. when the call transfer can be considered effective on FP side), 
the FP shall issue a call identifier update for the PP target of the call transfer, as shown in figures 17 and 18, indicating 
the call identifier of the transferred call as updated call identifier. 

Call transfer abort: 

The PP may release the internal call before the call transfer is requested, this is handled as a regular parallel call release 
(see clause 7.4.3.5.4). (No later call transfer is then possible). 

The PP may abort a call transfer after the call transfer request has been actually sent to the FP. To achieve the user 
abort, the PP shall send a call release to the FP, using "Call release and call release rejection" of clause 7.4.3.5.4 to 
release the parallel call initiated for the transfer. The speech path shall be then automatically switched to the waiting 
peer. 

NOTE 1 : Implementation of call transfer abort on PP side is not strictly necessary except for the announced call 
transfer case (see clause 7.4.3.6, "No answer from transfer target" section). 

MMI independence: 

The requirements and flowcharts of the call transfer procedures described below allow various user experiences. For 
example the following MMI implementations are compatible: 

Implementation 1: A dedicated call transfer button/menu/action is offered each time the user establishes a second call 
(a 'call transfer request' is sent to the FP as soon as the user selects this option). Then the user 
separately hangs up, which triggers the sending of a {CC-RELEASE} to the FP. 

Implementation 2: Establishing a second internal call and hanging up is considered as an implicit call transfer request 
from the user. After user hang-up, the PP sends in a row a 'call transfer request' and a 
{CC-RELEASE} to the FP. 

NOTE 2: In implementations 1 and 2, a user hang-up can never be considered as a user request for call transfer 
abort. In particular, offering call transfer abort to the user with implementation 2 would require a 
dedicated MMI item (e.g. re-press the INT key). 

Implementation 3: same implementation as implementation 1 except that the FP sends a {CC-RELEASE} message 
after reception of the call transfer request from the PP. 

CLIP and CNIP. Procedures "Remote party CLIP on call transfer" (see clause 7.4.3.6.4) and "Remote party CNIP on 
call transfer" (see clause 7.4.3.6.5) shall be used. 

7.4.3.6.1 Announced call transfer procedure 

For the "Announced call transfer" procedure, all requirements of clause 7.4.3.6 apply. Additionally, if the control code 
is sent after establishing the connection with the transfer target, allowing for a transient call with the transfer target, the 
transfer is defined as announced. 

Announced call transfer "failure" cases: 

No answer from transfer target: when the transfer target does not answer, the FP should stop the call presentation 
upon timer expiry, and then provide the initiating PP with an off -hook warning tone according to "Tones provision" 
NG1.N.20 procedures. The initiating PP shall then abort the call transfer as described in call transfer abort section of 
clause 7.4.3.6. 
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NOTE 1 : In other words, the present "Announced call transfer" procedure requires implementation of a call 

transfer abort in order to be able to resume the call with the initial remote party (parallel call release 
before the call transfer is requested). 

NOTE 2: Despite the announced call transfer means that the transfer target answers the call, this sub procedure 
cannot be considered as out of scope of the announced call transfer procedure as it corresponds to a 
possible failure case. 

Waiting peer premature hang-up: Premature hang-up occurs if the waiting peer hangs up after the FP has received 
the call transfer request but before the waiting peer and transfer target were connected. In that case the FP shall ignore 
the call transfer request. The initiating PP may either continue with the second call (especially if it received the waiting 
peer release information), or release it. 

NOTE 3: If the waiting peer hangs up before the FP has received the call transfer request, the FP cannot assume 
that a call transfer was going to happen and is still in a regular double call scenario. The FP should 
therefore keep the second call going (whether still presented or already connected). If a subsequent call 
transfer request is however received, it is also ignored as it refers to an idle call id. 

NOTE 4: When the initiating PP receives the release information resulting from the waiting peer hang-up, it should 
not send the call transfer request even if already requested by the user. 
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PP1 



FP 



call established 
(external or internal) with call id 1 



Try to establish parallel internal call 2 

CC-INFO 




PP2 



« MULTI-KEYPAD, 1 7H + terminal id number » 
CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call proc > 



CC-INFO Ring-back tone 

^ « SIGNAL value = '01 'H » If required by the Tones provision' feature 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '2'H > 

< id type/subtype = 'Call status', value = 'CS call alerting > 

» 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '2' > 

< id type/subtype = 'Call status', val = 'CS call connect' > » 




CC-SETUP 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '2'H > 

< id type/subtype = 'Call status' value ='CS call setup' > 



CC-ALERTING 



CC-CONNECT 



Call 
pick-up 



CC-CONNECT-ACK 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '2' > 

< id type/subtype = 'Call status', val = 'CS call connect' > >: 



call 2 established for announcing call transfer 



Call transfer request 



CC-INFO 



« MULTI-KEYPAD, info = '1C 34'H » 
« CALL-INFORMATION, 
< id type/subtype = 'Call identifier' value = TH > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '1 ' > 

< id type/subtype = 'Call status', val = 'CS idle' > 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '2' > 

< id type/subtype = 'Call status', val = 'CS idle' > 

CC-RELEASE 



CC-RELEASE-COM 



Line of the transferred call 
if external (see note 9) 




CC-INFO 



« CALL-INFORMATION, 

< id type = 'Line id' subtype = 'external call' 

value = 'transferred call line id' = 'u' ; 

< id type='Line identifier', subtype='line type information', 

value = 'xy'E 

< id type/subtype = 'Call identifier' value = zh > 

< id type = 'Call id' subtype = 'Updated call id' val = TH : 

< id type/subtype = 'Call status', val = 'CS call connect' > 

» 



Figure 17: Announced call transfer (example with internal target PP2): 
"call transfer request" after {CC-CONNECT} 
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NOTE 5: The Call Control message sequence in figure 17 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 6: PP2 may be idle or busy (involved in another call). If busy, PP2 would receive a parallel internal 
incoming call instead of a first internal incoming call. 

NOTE 7: A multiple call line may not support the additional internal call. In that case, PP1 will receive back a busy 
line notification, which will terminate the procedure. 

NOTE 8: In figure 17, the second call is established using the "Outgoing parallel call initiation" procedure of 
clause 7.4.3.5.1; however, any procedure leading to two parallel calls may precede the call transfer 
procedure. 

NOTE 9: The call id update at the end of figure 17 contains the line id value and the 'line type information' of the 
transferred call, in order to inform PP2 of the line (and line type) used for this call. 



7.4.3.6.2 Unannounced call transfer procedure 

For the "Unannounced call transfer" procedure, all requirements of clause 7.4.3.6 apply. Additionally, if the control 
code is sent without knowing whether the transfer target would actually answer, the transfer is defined as unannounced. 

Unannounced call transfer "failure" cases: 

No answer from transfer target: When the transfer target does not answer, the FP should stop the call presentation 
upon timer expiry. The FP should then call back the initiating PP to re-connect the waiting peer party. 

Waiting peer premature hang-up: Premature hang-up occurs if the waiting peer hangs up after the FP has received 
the call transfer request but before the transfer target answered. If not already done at the time the waiting peer hangs 
up, the FP shall release the second call toward the initiating PP in response to the received 'call transfer request', as for a 
successful call transfer. The FP shall then stop the presentation of the second call to the transfer target. 

NOTE 1 : If the waiting peer hangs up before the FP has received the call transfer request, the FP cannot assume 
that a call transfer was going to happen and is still in a regular double call scenario. The FP therefore 
keeps the second call going. If a subsequent call transfer request is however received, it is ignored as it 
refers to an idle call id. 

NOTE 2: If the initiating PP receives the release information resulting from the waiting peer hang-up, it should not 
send the call transfer request even if already requested by the user. 
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PP 1 



call established 
(external or internal) with call id 1 



Try to establish parallel internal call 2 

CC-INFO 




FP 



PP 2 



« MULTI-KEYPAD, 1 7H + terminal id number » 
CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call proc > 



CC-INFO 



Ring-back tone 



« SIGNAL value = '01 'H » 



If required by the 'Tor es provision' feature 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '2'H > 

< id type/subtype = 'Call status', value = 'CS call alerting > 

» 



Call transfer request 



CC-INFO 



« MULTI-KEYPAD, info = '1C 34'H » 
« CALL-INFORMATION, 
< id type/subtype = 'Call identifier' value = TH > 

» 

CC-INFO 



« CALL-INFO, < id type/subtype = 'Call identifier', value = T > 

< id type/subtype = 'Call status', val = 'CS idle' > 

CC-INFO 

CALL-INFO, < id type/subtype = 'Call identifier', value = '2' > 

< id type/subtype = 'Call status', val = 'CS idle' > 



CC-RELEASE 



CC-RELEASE-COM 



Line of the transferred call 
if external (see note 6) 



CC-SETUP 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier' value = '2'H > 

< id type/subtype = 'Call status' value ='CS call setup' > 



CC-ALERTING 



CC-INFO 



« CALL-INFORMATION, 

< id type = 'Line id' subtype = 'external call' 

value = 'transferred call line id' = 'u' > 
< id type='Line identifier', subtype='line type information', 
value = 'xy'B > 

< id type/subtype = 'Call identifier' value = '2'H > 

< id type = 'Call id' subtype = 'Updated call id' val = TH > 

< id type/subt = 'Call status' val ='CS call under transfer' > 

CC-CONNECT Call pick-up 



CC-CONNECT-ACK 



CC-INFO 

« CALL-INFO, 

< id type/subtype = 'Call id', value = T > 

< id type/subtype = 'Call status', val = 'CS call connect' > 



Figure 18: Unannounced call transfer (example with internal target PP2): 
"call transfer request" before {CC-CONNECT} 
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NOTE 3: The Call Control message sequence in figure 18 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 4: PP2 may be idle or busy (involved in another call). If busy, PP2 would receive a parallel internal 
incoming call instead of a first internal incoming call. 

NOTE 5: A multiple call line may not support the additional internal call. In that case, PP1 will receive back a busy 
line notification, which will terminate the procedure. 

NOTE 6: The call id update at the end of figure 18 contains the line id value and the 'line type information' of the 
transferred call, in order to inform PP2 of the line (and line type) used for this call. 

7.4.3.6.3 Call re-injection to the system (external or internal) 

The purpose of the "Call re-injection to the system (external or internal)" procedure is to transfer a call (external or 
internal) -announced or unannounced- to all PPs. Both methods (announced and unannounced) shall be supported. 

All requirements of clause 7.4.3.6 apply; the only difference being that the initiator requests an internal general call 
instead of an internal call to a targeted PP. 

NOTE 1: Internal general call is defined in Generic Access Profile (GAP) EN 300 444 [12]. 

When the transferred call is internal (i.e. waiting peer entity is another PP), the FP shall not present the call to this PP. 

Call re-injection "failure" cases: 

Depending on whether the call re-injection is announced or unannounced, the provisions of clause 7.4.3.6.1 or 7.4.3.6.2 
in case of call transfer failure respectively apply with the following rules: 

• Provisions applying to the transfer target before picking up apply here to all PPs except the initiating PP. 

• Provisions applying to the transfer target after picking up apply here to the answering PP only. 
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PP1 



FP 





Call 1 established 
(external or internal) 



Initiate setup of parallel internal general call 

CC-INFO 



« MULTI-KEYPAD, 17H + '*' » 

Call transfer request 

CC-INFO 



« MULTI-KEYPAD, '1C 34'H » 
CC-RELEASE 



CC-RELEASE-COM 



r 



For each idle PP ■< 



r 



For each PP already in use , 
(if the line implements the "Multiple < 
calls" feature and is in "multiple call" 



Any PP (except PP1) 

attached to the same 
line 



Paging of the idle PP 




CC-SETUP 



CC-ALERTING 



If this PP picks up: 

CC-CONNECT 



ui 



sfer comDlete 



CW indication to the PP in use 
CC-INFO 



« CALLING PARTY NUMBER » 
« SIGNAL value = 'CW = '07'H » 

If this PP accepts the waiting call 
CC-INFO 



« "KEYPAD", info = '1C 35'H » 
unannounced call transfer complet* 



t 



Figure 19: Use of 'unannounced call transfer' as a way to re-inject a call into the system 

NOTE 2: The Call Control message sequence in figure 19 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 3: For the sake of simplicity in figure 19, call information is not shown and independent timelines are used 
on the left and right hand sides. Implementations will follow the messages content and sequence 
described in clauses 7.4.3.6.1 and 7.4.3.6.2. 



7.4.3.6.4 Remote party CLIP on call transfer 

"Remote party CLIP on call transfer" shall be used when a call transfer occurs between the remote parties of a double 
call. It is defined as follows: 

• A first call between a first party (A, transferring party) and a second party (B, "remote" party) is supposed to 
have been completely established. This first call may be external or internal. 
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• A second internal call between A and a third party (C, the PP target of the call transfer) is either already 

established (announced call transfer) or being established (unannounced call transfer). "Remote party CLIP on 
call transfer" shall be used on announced or unannounced call transfer. 

"Remote party CLIP on call transfer" occurs in the FP after reception of the "call transfer request" from the transferring 
party. The remote party CLIP (of B), if available, shall be indicated by sending the «Calling Party Number» 
information element in a {CC-INFO} message. 

NOTE 1 : "Remote party CLIP on call transfer" is applicable when the third party C is internal (that is, registered to 
the same PP as the transferring party A). 

NOTE 2: C successively receives the usual CLIP (of A) and the "Remote party CLIP on call transfer" (of B). 

NOTE 3: The call transfer target PP will differentiate the remote party CLIP/CNIP on call transfer from the 
CLIP/CNIP on call waiting thanks to the associated call id. 

If the remote party is external and was the target of an outgoing call, the FP never received a CLIP for this party and 
shall therefore create an 'artificial' CLIP for it. See table 17b for the parameter values used for an artificial CLIP. 



Table 17b: Values used for an artificial CLIP (transferred outgoing call case) 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Calling party 
number» 








<Numbertype> 


Unknown 




<Numbering plan id> 


Unknown 




Presentation 
indicator 


Presentation allowed 




<Screening indicator 


User provided, verified, and 
passed 




<Calling party 
address> 


All 





NOTE 4: When post dialling (e.g. for a PSTN call) the FP should nevertheless record the dialled number for the 
case the call will be transferred. 

7.4.3.6.5 Remote party CNIP on call transfer 

The "Remote party CLIP on call transfer" procedure applies unchanged, except that: 

• CLIP is replaced everywhere with "CNIP". 

• If the remote party is external and was the target of an outgoing call, the FP never received a CNIP for this 
party. The FP shall search the Contact List for an entry matching the dialled digits: 

if such an entry exists, the FP shall create an 'artificial' CNIP for the remote external party, using the 
"Name" and "First name" fields of that entry (provided these fields are not both empty). See table 17c for 
the parameter values used for an artificial CNIP; 

if such an entry does not exist, or if the "Name" and "First name" fields are both empty, the FP shall not 
send any CNIP. 

NOTE 1 : If both CLIP and CNIP are sent to the PP it is sufficient to display one of them. It is optional to display 
both. 
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Table 17c: Values used for an artificial CNIP (transferred outgoing call case) 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Calling party 








name» 


Presentation indicator 


Presentation allowed 






<Screening indicator 


User provided, verified and 
passed 






<Calling party name> 


All 




A 




FP B 


C 




(internal or external) 



(internal) 



call 1 established 



establish parallel internal call 2 
CC-INFO 



« MULTI-KEYPAD, info = '17'H + number » 



ring-back tone 
CC-INFO 



« SIGNAL value = '01 'H » 
call transfer request 

CC-INFO 



« MULTI-KEYPAD, info = '1C 34'H » 




CC-SETUP (see note 4) 



« CALLING PARTY NUMBER » of A 
« CALLING PARTY NAME » of A 

CC-ALERTING 



if announced call transfer 
CC-CONNECT 



if unannounced call transfer 
CC-CONNECT 



Remote party CLIP on call transfer 

CC-INFO (see note 4) 



« CALLING PARTY NUMBER » of B 
«CALLING PARTY NAME » of B 

if unannounced call transfer 
CC-CONNECT 



Call 
pick-up 



Call 
pick-up 



Call 
pick-up 



Figure 20: Remote party CLIP and CNIP on call transfer 

NOTE 2: The Call Control message sequence in figure 20 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 3: On figure 20, three possible positions for the {CC-CONNECT} message are shown. 

NOTE 4: CNIP for internal handsets is handled according to the provisions of GAP "Internal Call CNIP" procedure 
((GAP) EN 300 444 [12], clause 8.44). 

NOTE 5: CNIP and CLIP might not fit in a single message; in that case one or more additional {CC-INFO} 
message(s) are used. 
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7.4.3.7 3-party conference with established external and/or internal calls 

The 3-party conference takes place either between 3 PPs on the same FP (based on 2 internal calls), or between 2 PPs 
and one remote party (based on one internal + one external calls), or between 1 PP and 2 remote parties (based on 
2 external calls). 

If the "Multiple lines" feature is implemented, the calls may be on two different lines. 
Initiating PP. The "initiating PP" is the PP requesting the conference call. 

If two parallel calls are established, one of them being the active call, and in order to establish a conference, the 
initiating PP shall send: 

• a 'conference call request' consisting in the control code 1CH as keypad information in a {CC-INFO} message, 
followed by 32H; 

• the call identifier of the on-hold call to be added to the active call in order to establish the conference, in a 
«CALL-INFORMATION» IE included in the same {CC-INFO} message. 

If there are several calls on hold, the PP shall select one of them (e.g. the former active call could be used) and the FP 
shall support all possible selections. 

NOTE 1 : However, a FP may not accept to create a conference call if there are more than one calls on-hold, as 
described in clause 7.4.3.7.1. 

The call id of the conference shall be chosen by the FP among the involved call ids (either the on-hold call id selected 
by the PP, or the active call id). 

If the conference call establishment is successful: 

• The FP shall indicate 'CS idle' call status to the initiating PP, for the call whose call id was not chosen as the 
conference call id. 

• The FP shall indicate 'CS conference connect' call status to all PPs participating in the conference call 
(including the initiating PP), with the chosen conference call id. The FP may send an intercept tone together 
with this call status to some or all of the PPs («SIGNAL» information element with signal value '02'H, 
'intercept tone'). 

• The FP shall issue a 'call identifier update' together with the 'CS conference connect' call status, to all PPs for 
which the call id (of the involved call) is different from the conference call id, as shown on figure 21. 

NOTE 2: For a 3 party conference call as described in the present procedure, there is only one PP at most requiring 
a call id update. More specifically: 

- if the on-hold call id is used as the conference call id, a call id update is sent to the non-initiating party 
involved in the active call, if internal; 

conversely, if the active call id is used as the conference call id, a call id update is sent to the 
non-initiating party involved in the on-hold call, if internal. 

NOTE 3: In a 3-party conference call, all PPs involved in the conference share the same call identifier for the 
3-party call. 

The FP may change the codec using the service change procedure (see clause 7.4.3.3, "Codec change for parallel 
calls"). 

When implementing the "3-party conference" feature, the FP shall set bit of the "Extended higher layer capabilities 
(part 2)" (see EN 300 175-5 [5], clause F.3). 
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PP 



FP 



The on-hold call id shall 
be used in the 
conference call request 



In this example, the FP 
chooses the on-hold call 
id as the conference call 




Ongoing calls (external or internal) 
Call id=1 , call status = 'CS call hold' 
Call id=2, call status = 'CS call connect' 



Conference call request (with on-hold call id) 

CC-INFO 




« MULTI-KEYPAD, info = '1C 32'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'on-hold call id' ='01 'H > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS idle' > 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS conference connect' > 

» 



Figure 21 : 3-party conference call establishment request 
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PP1 



FP 



PP2 



The on-hold call id 
shall be used in 
the conference call 
request 



First call established (external or internal) 
Call id=1 , call status = 'CS call hold' 




Second call established, (internal), 
with call id =2, call status = 'CS call connect' 



CC-INFO 



« MULTI-KEYPAD, info = '1C 32'H » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', 
value = 'on-hold call id' ='01 'H > 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', 

value = 'active call id ' = '02'H > 

< id type/subtype = 'Call status', 

value = 'CS idle' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', 

value = 'on-hold call id' = '01 'H > 

< id type/subtype = 'Call status', 

value = 'CS conference connect' : 




CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', 

value = 'current call id' ='02'H > 

< id type = 'Call identifier', 

subtype = 'Updated call identifier', 
value = 'on-hold call id' ='01 'H > 

< id type/subtype = 'Call status', 

value = 'CS conference connect' > 



As the conference call id chosen is the 
on-hold call id, and the non initiating 
party involved in the active call is 
internal, it receives a call id update. 



> 



In this example, the FP 
chooses the on-hold 
call id as the 
conference call id. 



J 



Figure 22: Call id update for the non-initiating PP 



7.4.3.7.1 Unsuccessful 3-party conference call 

If the conference call request is unsuccessful, e.g. because PP is involved in more than 2 calls: 

• the FP shall send a negative acknowledgment as described in clause 7.4.3.4 (call status of the targeted call 'CS 
call hold' re-sent, along with call status reason 'control code failed'). 

7.4.3.7.2 3-party conference call release 

If the conference call is later transferred from the initiating PP to a target PP (using the call transfer feature [NG1.N.8]) 
the target PP shall play the role of the "initiating PP" in the following clauses. 

Release from one of the (non initiating) parties: 

The procedure "Call release and call release rejection" of clause 7.4.3.5.4, can only be used if the PP is involved in a 
conference and in another call (in other words, when the conference is a parallel call) in order to terminate the PP 
participation in one of these calls. In particular, they cannot be used by the FP to notify the PP when one of the remote 
parties hangs up (otherwise, this would exclude the PP from the conference call). 
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When one of the (non-initiating) parties hangs up during a 3PTY conference call: 

• the conference call shall become a regular two-end call; 

• the FP shall send the call status 'CS call connect' to the remaining PP (or PPs) involved in the resulting regular 
2-end call together with the line identifier if the remaining party is external; 

• the FP shall send to the PP (or PPs) the number of the remaining other party in a «CLIP» IE, if this number 
is available; 

NOTE 1 : If the other party is external and was included in the conference call as a result of an outgoing call, the FP 
never received a CLIP for this party and will have to create an 'artificial' CLIP for it. 

• the FP should issue a tone indication to the remaining parties. 

The 'CS idle' call status cannot be used by the FP to notify the PP when one of the remote parties involved in the 
conference hangs up. Sending this call status causes the PP to be excluded from the conference call. 

Release from the 3PTY conference initiating PP: 

When the initiating PP of the conference hangs up during a 3PTY conference call, the conference call shall be released 
when the two other parties are external. If one or more of the other parties is internal, the behaviour is left free to the 
implementation: the conference call may be released or become a regular two-end call between the remaining parties 
(i.e. can be used as an alternate method to perform a simple call transfer procedure). 



PP 



FP 




3-party conference established 




CC-RELEASE 



CC-RELEASE-COM 
H 



Figure 23: 3-party conference release 

If the conference call becomes a regular two-end call, all provisions of the 'Release from one of the (non-initiating) 
parties' subsection regarding the sending of a 'CS call connect' call status, of a CLIP, and of a tone indication to the 
remaining PP (or PPs) apply. 

Release of one of the parties from the 3PTY conference initiating PP: 

Releasing a remote party from the 3PTY conference initiating PP is not systematically possible as there is only one call 
id assigned for the conference call. However, the following behaviour is allowed: 

If the conference call was established in one of the following contexts: 

• either with two external parties on two separate lines (FP using the multiple lines features [NG1.N.14]); or 

• with one internal and one external parties; 

then the initiating PP may release a remote party using a parallel call release command with the line identifier (no call 
identifier sent along). The FP shall support this type of release. 

NOTE 2: For PSTN networks, this allows the PP to get rid of a remote party that hanged up and for which the 
network plays an infinite release tone. 

If the conference call becomes a regular two-end call, all provisions of the 'Release from one of the (non-initiating) 
parties' subsection regarding the sending of a 'CS call connect' call status, of a CLIP, and of a tone indication to the 
remaining PP (or PPs) apply. 
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7.4.3.8 Intrusion call (from PP to FP) 

Intrusion call is a simple way to set up a 3-party conference call, with an existing external active call on another PP. 
This service comes in two procedures, implicit and explicit: 

• 'implicit intrusion call' mimics the usual behaviour of two PSTN wired phones connected to the same physical 
analogue line; 

• 'explicit intrusion call' can be thought of as a menu oriented service allowing intrusion into potentially any call 
active on the system. 

NOTE: Intrusion call is also known as "barging in". 

A line setting also exists to allow or dis-allow the call intrusion. This setting applies to implicit and explicit intrusion 
call procedures. 

When implementing the feature, the FP shall set bit a^2 of the "Extended higher layer capabilities (part 2)" 
(see EN 300 175-5 [5], clause F.3). 

7.4.3.8.1 Implicit intrusion call into a line in "single call" mode 

This procedure applies to the FP and to an idle PP on a line configured in "single call" mode. 

NOTE 1 : "Implicit call intrusion" if implemented should be a configurable feature of the single call mode line. 
'Implicit call intrusion' for non early {CC-CONNECT} implementation: 

If PP1 is involved in an active external call and PP2 wishes to participate in a 3-party conference with PP1 and the 
remote party: 

• PP2 shall attempt to make an external call, and shall specify the external line to use (possibly 'None') using 
either the {CC-SETUP} or a {CC-INFO} message (see clause 7.4.5.2). Implicit call intrusion shall succeed if 
the following conditions are all met: 

1) The line to use is entirely determined, i.e. PP2 is attached to a single line or PP2 specifies the line to use 
(i.e. does not use 'None'). 

NOTE 2: In other words, condition 1 is met if any of the following cases applies: 

The PP is attached to a single line, and specifies this line in { CC-SETUP } or { CC-INFO } . 

The PP is attached to a single line, and specifies 'None' in {CC-SETUP} or {CC-INFO}. 

■ The PP is attached to several lines, and specifies one of these lines (excluding 'None') in 
{ CC-SETUP } or { CC-INFO } . 

2) There is already an active call on that line. 

3) The field 'Multiple calls mode' of the corresponding line settings (see clause 7.4.1 1.4.8) is set to '30'H 
('Single call mode'). 

4) The field Intrusion call' of the corresponding line settings (see clause 7.4.1 1.4.9) is set to '31'H 
('allowed'). 

• If the PP line selection is done in the {CC-SETUP} message (see figure 24): 

This message shall be directly acknowledged by the FP with a {CC-CONNECT} message with call 
status 'CS conference connect' and the call identifier of the intruded call. 

No {CC-SETUP-ACK}, nor {CC-CALL-PROC} message shall be used. 

The line id of the intruded call, together with the line type information, shall be sent as described in 
clause 7.4.5.2.2 (including possibly in the {CC-CONNECT} as allowed for call intrusion cases). 
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• If the PP line selection is done in a subsequent {CC-INFO} message (see figure 25): 

After reception of the {CC-SETUP}, the FP shall assign a new call id as for any new outgoing first call 
(e.g. in a {CC-SETUP-ACK} message with call status 'CS call setup ack'). 

As soon as the PP line selection is received, the FP shall acknowledge it with a {CC-CONNECT} 
message, with call status 'CS conference connect' and shall update the call id in the same message to the 
intruded call id value. If the intruded call is external, the {CC-CONNECT} message shall include the 
line id of this call (together with the line type information). 

• The FP shall notify PP1 with a {CC-INFO} message containing: 

The information element «CALL INFORMATION» with the same call identifier and call status. 

If required by the "Tones provision" feature, the information element «SIGNAL» with the value 02H 
indicating 'Intercept tone on'. 

The FP shall generate automatically a conference call audio stream between the three parties. 

'Implicit call intrusion' for early {CC-CONNECT} implementation: 

The above description applies with the following modifications: 

• If the PP line selection is done in the {CC-SETUP j message (figure 24): 

Upon reception of {CC-SETUP}, the FP shall send back a {CC-CONNECT} message with intruded call 
id but no call status. 

The existing {CC-CONNECT} message (including 'CS conference connect' and intruded call id) shall be 
replaced with a {CC-INFO} message with the same contents. 

No 'CS call setup ack' nor 'CS call proc' call status shall be used. 

• If the PP line selection is done in a subsequent { CC-INFO j message (figure 25): 

Upon reception of {CC-SETUP}, the FP shall send back a {CC-CONNECT} message with newly 
assigned call id but no call status, 

The following {CC-SETUP-ACK} message shall be replaced by a {CC-INFO} message with the same 
contents (including 'CS call setup ack' call status). 

The existing {CC-CONNECT} message (including 'CS conference connect' and call id update) shall be 
replaced with a {CC-INFO} message with the same contents. 

No 'CS call proc' call status shall be used. 

Error processing: 

If conditions 1, 2, 3, and 4 are not all met, the FP shall handle the call as a regular outgoing call. More specifically: 

• If conditions 1 is met but condition 2 is not met, the FP shall place the new outgoing call on the (idle) line. 

• If conditions 1, 2 are met but condition 3 is not met, the FP shall attempt to place an additional call on the 
multiple call line if possible. If this is not possible, it shall use procedure 7.4.8.3, "Busy system or line 
notification". 

• If conditions 1, 2 and 3 are met but condition 4 is not met, the FP shall always use procedure 7.4.8.3, "Busy 
system or line notification". 

Use of the procedure "Busy system or line notification" of clause 7.4.8.3 implies sending a first CC message back to the 
PP (different from {CC-INFO}). For the case no such message exists in the successful case (see figure 24: PP line 
selection in {CC-SETUP} with non-early CC-CONNECT implementation), a { CC-CALL-PROC } shall be used in the 
error case for this purpose. 
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PP2 

attached to line u 
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attached to line u 



FP 



Network 



The PP sets up the call 
and selects the line to be 
used (possibly 'None') 



External Call established on line u with call id 1 



CC-SETUP 



T 

« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 



I 



CC-CONNECT 



If required by the Tones provision' feature 




« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external', value = 'u'> 

< id type = 'Line identifier', subtype='line type information', 

value = 'xy'B > 

< id type/subtype = 'Call identifier', value = 'call id V> 

< id type/subtype = 'Call status', value = 'CS conf. connects 



If required by the 'Tones provision' feature 




CC-INFO 



« SIGNAL, value = '02'H » 



PP2 «CALLING-PARTY-NUMBER» 

« CALL-INFORMATION, 

< Identifier type = 'Call identifiers 

< Identifier subtype = 'Call identifier^ 

< Identifier value = 'call id 1 ' > 

< Identifier type = 'Call status'> 

< Identifier subtype = 'Call status'> 

< Identifier value = CS conf. connect' > 



3-oartv call establishment 




Figure 24: Successful implicit call intrusion with PP line selection in the {CC-SETUP} 
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Network 
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be used (possibly 'None') 




External Call established on line u with call id 1 



CC-SETUP 
T 



CC-SETUP-ACK 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'call id 2'> 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» CC-INFO 



+ 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'call id 2'> 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 




CC-CONNECT 
T 



If required by the 'Tones provision' feature « SIGNAL, value = '02'H » 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external", value = 'u'> 

< id type='Line identifier', subtype='line type information', value = 'xy'B > 

< id type/subtype = 'Call identifier', value = 'call id 2'> 

< id type = 'Call identifier', subtype = 'Updated call id', value = 'call id V> 

< id type/subtype = 'Call status', value = 'CS conf. connects 



If required by the 'Tones provision' feature 




CC-INFO 



« SIGNAL, value = '02'H » 

PP2 «CALLING-PARTY-NUMBER» 
« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier^ 

< Identifier value = 'call id 1 ' > 

< Identifier type = 'Call status'> 

< Identifier subtype = 'Call status'> 

< Identifier value = CS conf. connect' > 



3-oartv call establishment 



Figure 25: Implicit intrusion call with PP line selection in a {CC-INFO} 

NOTE 3: The Call Control message sequence in figure 24 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 4: In addition to the call status 'CS conference connect', CLIP of PP2 sent together with the call id of the 
external call warns PP1 of a call intrusion attempt. 

NOTE 5: If the selected line is not a "single-call" mode line, the DECT system will try to make an outgoing call. 

NOTE 6: In figures 24 and 25, if PP2 is attached to a single line, it may specify 'None' instead of 'line u'. 

When the intrusion call is established, the provisions of clause 7.4.3.7, "3-party conference with established external 
and/or internal calls" apply (including release related provisions). 
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7.4.3.8.2 Explicit intrusion call 

The present procedure applies to the FP, an idle PP (the intruder), and a PP with an active call (the intruded PP). With 
explicit call intrusion, the PP uses a specific control code while initiating the setup of a call, in order to indicate to the 
FP that a call intrusion is attempted. 

There are two available types of explicit call intrusion: handset intrusion and line intrusion. These two types of explicit 
intrusion are exclusive. 

Handset intrusion: When using handset intrusion, the PP uses the terminal id number of the targeted handset to request 
intrusion of the call active on that handset. No line id specification is used (not even 'None'). 

Handset intrusion succeeds if there is an active call on the targeted handset (there can be only one). This active call may 
be external or internal. 

NOTE 1 : Only handset intrusion allows the intrusion of an internal call. 

The FP may forbid handset intrusion if the intruder and intruded PPs are not attached to a common line. 

Special case. It is allowed to use '*' as the target of handset intrusion. Handset intrusion with target '*' succeeds if there 
is one and only one active call (external or internal) in the DECT system. 

Line intrusion: When using line intrusion, the PP uses the line id of the targeted line to request intrusion into an active 
external call on that line. No terminal id number is used (not even '*'). The PP should not specify a line it is not attached 
to (see clause 7.4.5.2.1). 

Line intrusion succeeds if there is a single active external call on the targeted line. The targeted line may be a single call 
or multiple call line. If a multiple call line, it may be configured in "multiple call" or "single call" mode. 

NOTE 2: Line intrusion only intrudes external calls. 

The FP could forbid a call intrusion from a PP not attached to the line of the external call to be intruded. 

Special case. It is allowed to use 'None' as the target of line intrusion. Line intrusion with target 'None' succeeds if there 
is one and only one active external call in the DECT system. 

NOTE 3: A 'line intrusion' is similar to an 'implicit call intrusion' (see clause 7.4.3.8.1), except that it is explicitly 
requested ('1C40H control code added in {CC-SETUP}): the procedure will always fail if the intrusion 
cannot be performed. On the contrary, an 'implicit call intrusion' may result in a regular outgoing call. 

Intrusion target: For handset intrusion, the intrusion target is the handset specified by the intruding PP (possibly '*'). 
For line intrusion, the intrusion target is the line specified by the intruding PP (possibly 'None'). 

PP and FP compliance with the 'Explicit call intrusion' procedure: 

A PP implementing the present procedure shall implement at least one of the two types of explicit call intrusion. 
A FP implementing the present procedure shall implement both types of 'explicit call intrusion'. 
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» 

cc-co'nnect 



If required by the 'Tones provision' feature « SIGNAL, value = '02'H » 
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« SIGNAL, value = '02'H » 



PP2 «CALLING-PARTY-NUMBER» 

« CALL-INFORMATION, ! 

< id type/subtype = 'Call identifier', value = 'call id 1'> 

< id type/subtype = 'Call status', value = 'CS conf. connects 



3-party call establishment 



Figure 26: Successful explicit call intrusion with intrusion target in {CC-INFO} 

NOTE 4: Figure 26 does not describe the case of a 'line intrusion' with intrusion target in {CC-SETUP}. 

NOTE 5: The Call Control message sequence in figure 26 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 
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The 'Explicit call intrusion' description slightly differs depending on whether a {CC-INFO}or the {CC-SETUP} is used 
by the intruding PP for specifying the intrusion target. The two use cases are therefore described below in separate 
subsections. 

NOTE 6: The described cases correspond to a non-early {CC-CONNECT} implementation. The differences 
applying for an early {CC-CONNECT} implementation are briefly described in a further subsection 
below. 

'Explicit call intrusion' with intrusion target specified in {CC-INFO} ('handset intrusion' or 'line intrusion'): 

If PP1 is involved in an active call and PP2 wishes to participate in a 3-party conference with PP1 and the remote party: 

• PP2 shall insert a call intrusion request, consisting in the control code 1CH followed by 40H in the 
{CC-SETUP} message. 

• The FP shall answer with a { CC-SETUP- ACK} message with call status 'CS call setup ack' and assigned call 
id. 

• PP2 shall then use one of two explicit intrusion use cases: 

1) Handset intrusion: PP2 sends the terminal id number of the handset owning the targeted call (external 
or internal), or '*' in order to intrude any handset, in a subsequent {CC-INFO} message (together with 
the received call id). PP2 does not send any line specification (not even the 'None' value): 

■ If '*' is not used and there is a call active on the specified terminal, this call (external or internal) 
shall be intruded. 

■ If '*' is used and there is a single active call (external or internal) in the system, this only call shall 
be intruded. 

2) Line intrusion: PP2 sends the line id of the targeted external call (without any terminal id number), or 
'None' in order to intrude any external call, in a subsequent {CC-INFO} message (together with the 
received call id): 

■ If 'None' is not used and there is a single active external call on the specified line, this only call 
shall be intruded. 

■ If 'None' is used, and there is a single active external call on the DECT system, this only call shall 
be intruded. 

• The FP shall answer the intruder (PP2) with a { CC-CONNECT } message including: 

a «CALL INFORMATION» IE containing: 

■ the call id of the intruded call; 

■ the call id update from early assigned call id to id of the intruded call; 

■ the call status "CS conference connect". 

if required by the "Tones provision" feature, the «SIGNAL» IE with the value '02'H indicating 
Intercept tone on'. 

NOTE 7: The «SIGNAL» IE may equivalently be sent in a { CC-INFO } following the {CC-CONNECT}. In that 
case, this {CC-INFO} also contains the (already updated) intruded call id. 

• No { CC-CALL-PROC } message shall be used. 

• If the intruded call is external, the line id, together with the line type information, shall be sent as described in 
clause 7.4.5.2.2 (including possibly in the {CC-CONNECT} for call intrusion cases). 

• The FP shall notify the intruded PP (PP1) of the intrusion with a {CC-INFO} message containing: 

a «CALL INFORMATION» IE containing the call id of the intruded call, and the call status "CS 
conference connect"; 



ETSI 



97 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



if required by the "Tones provision" feature, the «SIGNAL» IE with the value 02H indicating 
Intercept tone on'. 

The FP shall generate automatically a conference call audio stream between the three parties. 

NOTE 8: In addition to the call status 'CS conference connect', CLIP of PP2 sent together with the call id of the 
external call warns PP1 of a call intrusion attempt. 

NOTE 9: In "multiple call" mode, simply initiating a call setup would lead to the setup of an additional call if the 
line can accept an additional call, or to a failure (busy tone signal received back). 

When the call intrusion is established, the provisions of clause 7.4.3.7, "3-party conference with established external 
and/or internal calls" apply (including release related provisions). 

'Explicit call intrusion' with intrusion target in {CC-SETUP} ('line intrusion' only): 

If PP2 uses 'line intrusion' with the line id specified in {CC-SETUP}, the steps described above shall be used with the 
following modifications: 

• PP2 shall send the line id of the targeted external call (without any terminal id number) together with the call 
intrusion request in the {CC-SETUP}message. 

• The FP shall answer with a {CC CONNECT} message with call status 'CS conference connect' and the 
intruded call id to PP2. 

• No { CC-SETUP- ACK } nor { CC-C ALL-PROC } message shall be used. 

• If the intruded call is external, the line id, together with the line type information, shall be sent as described in 
clause 7.4.5.2.2 (including possibly in the {CC-CONNECT} for call intrusion cases). 

All other provisions described above apply with no modification. 

'Explicit call intrusion' for an early {CC-CONNECT} implementation: 

In the case of early {CC-CONNECT} implementation, all the above applies with the following modifications: 

• For a line intrusion with intrusion target in { CC-SETUP } : 

The {CC-SETUP} message shall be answered by the FP with a {CC-CONNECT} with intruded call id 
and no call status. 

The existing {CC-CONNECT} (including 'CS conference connect' and intruded call id) shall be replaced 
with a {CC-INFO} with exactly the same contents. 

No 'CS call setup ack' nor 'CS call proc' call status shall be used. 

• For a line or handset intrusion with intrusion target in subsequent { CC-INFO } : 

The {CC-SETUP} message shall be answered by the FP with a {CC-CONNECT} with the newly 
assigned call id and no call status. 

The {CC-SETUP-ACK} shall be replaced with a {CC-INFO} with the same contents (including 'CS call 
setup ack'). 

The existing {CC-CONNECT} message (including 'CS conference connect' and call id update) shall be 
replaced with a {CC-INFO} with exactly the same contents. 

No 'CS call proc' call status shall be used. 

Error processing: 

In all other cases, that is: 

• for handset intrusion: 

if there is no external or internal call active on the specified handset; 
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if '*' is used, if there is no external or internal call active (or more than one) in the system; or 

the call to be intruded is external, and the field Intrusion call' of the corresponding line settings (see 
clause 7.4.1 1.4.9) is set to '30'H ('not allowed'); 

• for line intrusion: 

if there is no external call or more than one external call on the specified line; 

if 'None' is used, if there is no external active call (or more than one) in the system; 

if the PP is not attached to the intruded line; or 

the field Intrusion call' of the corresponding line settings (see clause 7.4.1 1.4.9) is set to '30'H ('not 
allowed'); 

• the FP shall use the "Busy system or line notification" procedure of clause 7.4.8.3, that is: 

after sending the first CC message, the FP shall send a {CC-INFO} message with call status 'CS call 
disconnecting' along with call status reason 'control code failed' and the same call id; 

the FP shall send a «CALL INFORMATION» IE with call status 'CS idle' in order to free the call id 
(on the intruding PP side only). 

Use of the procedure "Busy system or line notification" of clause 7.4.8.3 implies sending a first CC message back to the 
PP (different from {CC-INFO}). For the case no such message exists in the successful case (line intrusion with 
intrusion target specified in {CC-SETUP}, in non-early CC-CONNECT implementation), a { CC-CALL-PROC } shall 
be used in the error case for this purpose. 

7.4.3.9 Internal call codec priority 
7.4.3.9.1 Description 

When performing an internal call between two wideband enabled PPs, the FP shall arrange that the call is finally 
established in a wideband codec rather than in a narrow band codec. Respectively in a super wideband codec rather than 
in a wideband or narrowband codec. 

As a consequence, in the particular case where both PPs present G.722 with highest priority, the internal call shall 
finally be established in Recommendation ITU-T G.722 [17]. 

Exception cases to this procedure are listed in clause 7.4.3.9.2. 

This procedure has been added to guarantee that the internal call will be established in the highest audio quality 
supported by both handsets involved in the internal call, at least when no other call is established at the same time in the 
DECT system. 

Two examples of support of this procedure are given hereafter: 

EXAMPLE 1 : When the «Codec List» information element is only specified at subscription registration and 
location registration phases. 

EXAMPLE 2: When the «Codec List» information element is specified at call setup phase. 

Figure 27 shows an example (example 1) with an internal call sequence where no codec list is specified at call setup and 
both PP-s support wideband (same codec list re-used as at location registration phase). 
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PP1 



FP 



PP2 



ACCESS RIGHTS-REQUEST 



« Codec List = G.722 G.726» 

ACCESS RIGHTS ACCEPT 



« Codec List G.722,. ..,G.726» 
LOCATE-REQUEST 



LOCATE-ACCEPT 



« Codec List = G.722,..., G.726» 
Initiate an internal call 



CC-SETUP 




«Basic Service=98» 


► 


CC-CALL-PROC 




M 




CC-CONNECT 




«Codec List = G.722» 



LC E_R EQ U EST P AG E (long) 



CC-SETUP 



«Basic Service=98» 

CC-CONNECT 



«Codec List = G.722» 
CC-CONNECT-ACK 



Figure 27: Internal call with no codec list at call setup 

Figure 28 shows example 2 with an internal call sequence where the codec list is specified at call setup and both PPs 
support wideband. 



PP1 



FP 



PP2 



CC-SETUP 


LCE_REQUEST_PAGE (long) 


► 

«Basic Service=98» 

«Codec List - G.722, G726» 

CC-CALL-PROC 


CC-SETUP 


< 

CC-CONNECT 


► 

«Basic Service=98» 

«Codec List=G.722, G726» 

CC-CONNECT 


< 

«Codec List = G.722» 

CC-CONNECT-ACK 


< 

«Codec List = G.722» 


► 



Figure 28: Internal call with codec list at call setup 
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NOTE: The Call Control message sequences in figures 26 and 27 should be understood as examples. The real 

sequences may also contain different Call Control messages or Call Control messages in another order or 
Call Control messages with other contents. 

7.4.3.9.2 Exception cases 

The following exceptions to the clause 7.4.3.9 shall apply: no requirement applies in the following cases: 

a) Case of internal call transfer. In this case, the PP requesting the transfer may specify any order for the codecs 
in the «Codec List» information element. For example, the codec used in the initial ongoing external call to 
be transferred may be given the highest priority in the «Codec List» information element sent by the PP for 
the parallel call. This could avoid two codec switching: one for each PP involved in the transfer. 

b) Cases of multiple calls handled by the FP at the same time, if critical for FP hardware resources. 

c) Specific implementations of PPs that have to support narrow band headsets. 

d) Specific implementations of PPs where battery autonomy is very critical. 

7.4.3.10 Handling of lines where second calls are signalled in-band 

The present procedure describes the 'Handling of lines where second calls are signalled in-band' feature. In other words 
it describes the rules specifically applicable to lines supporting 'double calls with in-band signalling' (DCIBS lines for 
short). Most notably, PSTN lines implementing 'PSTN double calls' are DCIBS lines, and possibly other types of lines 
implementing similar rules. 

The present procedure describes the use by the PP and FP of a limited subset of the procedures of clause 7.4.3.5, 
"Common parallel call procedures", with some adjustments, so that they can be used with 'double call with in-band 
signalling' lines. 

The PP shall support the 'Handling of lines where second calls are signalled in-band' feature additionally to the parallel 
calls relating features. However the present procedure is designed so that the PP behaviour will be very close the its 
behaviour on regular lines. The PP is informed of the type of line through the 'line type information' sent along with the 
line identifier. 

The FP may support the feature depending on the type of lines it is designed to be connected to. A FP could be designed 
to support only DCIBS lines and is allowed in that case not to support all common parallel call procedures (see 
clause 7.4.3.10.3.1 for more details). However the features and procedures to be supported in that case rely heavily on 
the corresponding features for regular lines with as few adjustments as possible. 

On the contrary, the handling of a first call on such lines does not require any modification of these procedures. This 
includes cases where the PP is idle when handling this first call, or already involved in a call but on another line. 

7.4.3.10.1 General requirements 

Double calls with in-band signalling line (DCIBS line): A 'double call with in-band signalling' (DCIBS) line is a 
legacy line on which second calls, incoming or outgoing, are handled using signalling 'in-band'. On such lines, the 
DECT FP has to send legacy network messages with limited semantics for handling second calls-incoming or outgoing. 
As a result: 

• The Network only delivers in-band tone based messages targeted at the user (i.e. invisible to the FP and PP). 

• For some DCIBS however, the network delivers an off -hook CLIP (see clause 3.1for a waiting call (or 'CLIP 
on call waiting') which allows the FP to be aware of the waiting call. This leads to the following two subtypes 
of 'double call with in-band signalling' lines, which can be distinguished by the way they handle second calls: 

Basic DCIBS lines: Line not supporting double calls, or supporting them but NOT delivering any 
off-hook CLIP for a waiting call. Such lines are considered as fully 'common parallel call' compliant 
lines, because the possibility of a second call on such lines is ignored from Part 3 perspective (although 
the use of transparent commands for handling them is still possible) and are handled in clause 7.4.3.10.2. 

Off-hook CLIP enabled DCIBS lines: Line supporting classic 'double call' procedures and delivering an 
off-hook CLIP for call waiting. Such lines are handled in clause 7.4.3.10.3. 
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NOTE 1: Both subtypes of 'double call with in-band signalling' lines are 'single call mode' lines. 

PP notification of the line type: For each external call, the FP shall indicate to the PP how the second call is handled 
on the line, using the 'second call type' flag (bit 2) of the 'line type information' as defined in table 17d below. 



Table 17d: Use of the 'Second call type' flag for DCIBS or non-DCIBS lines 



Line type 


SCT 


Applying 
clause 


Comment 


Part 3 fully 
compliant line 





7.4.3 (without 
7.4.3.10) 


Fully 'Common parallel call procedures' compliant lines 


Basic DCIBS line 





7.4.3.10.2 


Use of 'Common parallel call procedures' (7.4.3 without 
7.4.3.10) for second calls management forbidden by the 
FP (negative acknowlegdement) 


Off-hook CLIP 
DCIBS line 


1 


7.4.3.10.3 


Such lines are the non-trivial DCIBS lines. 'Common 
parallel call procedures' are used as much as possible 



NOTE 2: The 'line type information' is a line identifier of subtype 'line type information' sent together with the line 
id from FP to PP. It also includes the 'network delay type' flag. See clauses 7.4.3.5.1, 7.4.3.5.2 and 
7.4.5.1. 

NOTE 3: Although a PSTN line is usually a DCIBS line, an enhanced FP may choose to handle a given PSTN line 
with the 'common parallel call procedures' if it is possible (e.g. by using a tone detector). In that case, the 
'Handling of lines where second calls are handled in-band' feature is not used (line type information 
'00'B). 

Transparent network directed commands: Transparent 'network directed' commands issued by the PP are not the 

main target of the present procedure, but are however dealt with in clause 7.4.3.10.4, as they can still be used to handle 
calls on such lines. Transparent commands generally use the 'R' key (coded as keypad information 15H) as the unique 
control code. 

7.4.3.1 0.2 Basic DCIBS lines 

Basic DCIBS lines: A basic double call with in-band signalling line (basic DCIBS line) is a DCIBS line not supporting 
double calls, or supporting them but NOT delivering any off -hook CLIP for a waiting call. 

NOTE 1 : A call waiting indication on such a line, being fully in-band, may be lost if the handset using this line is 
involved in a call on another line, (neither heard by the user, nor detected by the FP). 

A basic DCIBS line shall be handled as a line only allowing a single call context from the 'Common parallel call 
procedures' point of view. More specifically: 

• The 'Common parallel call' procedures shall not apply for handling second calls. In other words, the FP shall 
handle the line as if it was not supporting double calls. In particular: 

If an 'outgoing parallel call initiation' (see clause 7.4.3.5.1) is attempted on such a line the procedure 
'Busy system or line notification' of clause 7.4.8.3 shall be used by the FP. 

The 'call waiting indication' procedure (see clause 7.4.3.5.2) shall not be used. 

NOTE 2: As the FP is not aware of waiting call on such lines, incoming second calls handling cannot use the 
'Common parallel call procedures'. For the overall consistency of call handling on such lines, these 
procedures are neither used for outgoing second calls. 

• Classical 'Double call' if available on the line shall be handled by the user with transparent network directed 
commands from PP to network and shall not be handled through 'Common parallel call' procedures. 

• The FP shall only assign a call id for the first call on that line. 

NOTE 3: 'Common parallel call' procedures still apply in multiple line context for commands involving several 
lines (e.g. call toggle to-and-fro a basic double call with in-band signalling' line). 
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Line type information: A basic DCIBS line shall respect the following rule for the line type information value: 

• 'Second call type' = 'SCT' = 'O'B, indicating that second calls are handled in a way compliant with 'common 
parallel call procedures'. 

NOTE 4: As only a single call context is considered on such lines, the behaviour of the PP and FP is fully 
compliant with the 'Common parallel call' procedures (no second call is considered). 

7.4.3.1 0.3 Off-hook CLIP enabled DCIBS lines 

7.4.3.1 0.3.1 General requirements for off-hook CLIP enabled DCIBS lines 

Off-hook CLIP enabled DCIBS lines: A 'Off-hook CLIP enabled DCIBS line' is a DCIBS line supporting classic 
'double call' procedures and delivering a off-hook CLIP for call waiting. For such lines: 

Second call handling, call statuses and call id: For off-hook CLIP enabled DCIBS lines: 

• For the handling of second calls, the PP shall use commands compliant with the 'Common parallel call 
procedures' (see clause 7.4.3.5). 

• In particular, a call id shall be assigned for a second call (incoming or outgoing). 

• It is allowed for the FP to send the call statuses 'CS call hold' and 'CS call connect' at a time not exactly related 
to the corresponding event in the network (if any). 

• Call statuses other than 'CS call hold' and 'CS call connect' may not always be available. Use of a 'tone 
detector' on FP side may enhance the set of call statuses the FP is able to send to the PP. 

Remote party hang-up for a second call: If a remote party hangs up one of two parallel calls the FP may not be aware 
of this event occurring in the network. As a result it may maintain both call contexts and not warn the PP (although the 
user himself may sometimes be aware of this event through the heard tone). Consequently: 

• the PP may maintain a superfluous second call context (and call id) until it hangs up itself, thus preventing the 
PP to accept or place a second call on the line: 

Issue 1: In that case, the user of the PP could be faced either with one of the two call contexts leading to 
an inexistent call, or with two equivalent call contexts (both handling the same call). 

• However, the FP may later on be indirectly informed of the call release in the network, when either a new call 
waiting occurs, or if the user initiates an outgoing second call (both events indicating that there were no two 
calls any longer on the line). In that case, the FP shall release the superfluous call context (CS idle with call id 
sent to the PP). This behaviour is called a 'late release' of the call (see clause 3.1). 

• In some cases however, the FP may not be able to know which of the two existing call contexts is to be deleted 
and shall choose one of the two contexts (e.g. the most probable one) and delete it: 

Issue 2: In that case the user may be faced with a call context showing wrong data. 

• The PP shall use its best endeavour to minimize the inconvenience caused by these issues for the user. 
Clause C.9.1 details some use cases illustrating these issues. 

Translation of commands into the network: The FP shall use its best endeavour to translate the requests issued as 
part of the 'Common parallel call procedures' into legacy commands understandable by the network. 

NOTE 1 : This does not mean that the PP should forbid the use by the user of legacy commands directly targeting 
the network. 

Line type information: An 'off-hook CLIP enabled DCIBS line' line shall respect the following rules for the line type 
information value: 

• The 'Network delay type ('NDT') should be '0'B, indicating that the line is a 'low delay' line; however the use 
of procedure 'Off-hook CLIP enabled double call with in-band signalling' lines' for lines with significant delay 
(NDT = 1) is still possible. 
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• 'Second call type' = 'SCT' = TB, indicating that second calls are handled (mostly; see note 2) with in-band 
signalling on network side. 

NOTE 2: As an exception to in-band signalling, on such lines, call waiting indications are not received in-band by 
the FP from the network. This exception allows the use of 'Common parallel call procedures' with some 
limitations. 

EXAMPLE 1 : An off-hook CLIP enabled PSTN line uses line type information '10'B ('Off-hook CLIP enabled 
DCIBS' line with low delay). 

EXAMPLE 2: A VoIP line mimicking the PSTN line behaviour including off-hook CLIP would use line type 
information ll'B ('Off-hook CLIP enabled DCIBS' line with significant delay). 

7.4.3.1 0.3.2 Applicable procedures and control codes 

Table 18 lists the restrictions and modifications that apply for a FP when handling an off-hook CLIP enabled DCIBS 
line (described in clause 7.4.3.10.3). If a FP only supports such lines the amended procedures only apply. 



Table 18: Restrictions applying to a FP when handling an off-hook CLIP enabled DCIBS line 



Feature 


Procedure 


Reference 


Comment 


Parallel Calls 




NG1.N.6 




Control messages 


7.4.3.2 


Amended by clause 7.4.3.10.3.2 
(table 19) 


Common parallel call 
procedures 




NG1.N.7 




Call release and call release 
rejection 


clause 7.4.3.5.4 


Network support is unlikely for parallel 
calls on DCIBS lines. In case of When 
there are two parallel calls, the FP 
may answer directly 'control code 
failed' 


Call waiting rejection 


clause 7.4.3.5.7 


Putting a call on-hold 


clause 7.4.3.5.8 


Resuming a call put on-hold 


clause 7.4.3.5.9 


Call transfer 




NG1.N.8 


Amended by clause 7.4.3.10.3.6 


3-party conference call 




NG1.N.9 


Amended by clause 7.4.3.10.3.7 


Call identification (and 
call statuses) 




NG1.N.13 


Amended by clause 7.4.3.10 and 
subsections 



Applicable control codes. Table 19 lists the restrictions and modifications that apply to control code handling by a FP 
for an off-hook CLIP enabled DCIBS line (described in clause 7.4.3.10.3). Other control codes apply with no change. 
When applicable, the FP shall translate commands into transparent network directed commands. 

If a FP only supports such lines, the amended procedures only shall apply (see also clause 6.10, table 9, note 2). 



Table 19: Control messages for control of parallel calls 



Procedure 


Control message 


Direction 


Notes 


Call release (of the indicated call) 


1CH 33H 


PP to FP 


See notes 1 and 5 


Call transfer request (external or internal) 


1CH 34H 


PP to FP 


See note 3 


Call waiting rejection 


1CH36H 


PP to FP 


See notes 1 and 2 


Putting a call on-hold 


1CH41H 


PP to FP 


See notes 1 and 4 


Resuming a call put on-hold 


1CH42H 


PP to FP 


See notes 1 and 4 


NOTE 1 : For a parallel call, the FP shall answer with a negative acknowledgement 'control code failed' if the 

command is not supported by the network. 
NOTE 2: After sending the negative acknowledgement, the FP shall send the 'CS idle' call status to the PP even if 

the command is not supported by the network. 
NOTE 3: If there are two calls on the off-hook CLIP enabled DCIBS line, the FP should answer the call transfer 

request with a negative acknowledgement 'control code failed' (see clause 7.4.3.10.3.6). 
NOTE 4: This control code is optional for the PP. 

NOTE 5: After sending the negative acknowledgement, the FP shall not send the 'CS idle' call status to the PP. 



7.4.3.10.3.3 Parallel calls within a 'off-hook CLIP enabled DCIBS' line 

There can be only two parallel calls within an 'Off-hook CLIP enabled DCIBS' line. The present procedure handles use 
cases with both call on the same 'Off-hook CLIP enabled DCIBS line': these use cases may require a special handing in 
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some cases (adjustments of the 'Common parallel call procedures' of clause 7.4.3.5) and are therefore described in detail 
in the present clause. 

NOTE: Two call use cases with two lines, and one call on each line (whatever the type of these lines) do not 
involve second calls and therefore do not deserve any specific handling (they are compliant with the 
'Common parallel call procedures' of clause 7.4.3.5). 

7.4.3.1 0.3.3.1 Outgoing parallel call initiation within an off-hook CLIP enabled DCIBS line 

This procedure applies to a 'Off-hook CLIP enabled DCIBS' line on which a first call has already been placed, and a PP 
busy with another call going on on the same line. 

Outgoing parallel call initiation. When the FP receives an outgoing parallel call initiation from the PP (external or 
internal), it shall use the 'Outgoing parallel call initiation' procedure of clause 7.4.3.5.1. In particular, the FP shall: 

• assign a second call id for new outgoing call, and notify it to the PP. 

• send a 'FP line confirmation' with the appropriated 'line type information' (see clause 7.4.3.10.3.1). 

The FP shall use its best endeavour to translate the "outgoing parallel call initiation" into network directed commands. 

7.4.3.10.3.3.2 Call waiting indication/acceptance/rejection within an off-hook CLIP enabled DCIBS 
line 

This procedure applies to an 'Off-hook CLIP enabled DCIBS' line, a call waiting on that line, and a PP busy with the 
first call on the same line. 

Call waiting indication: When the FP receives an off-hook CLIP from the network indicating an incoming second call, 
the FP shall: 

• assign a new call id for the waiting call; 

• send a call waiting indication to the PP as defined in clause 7.4.3.5.2 (i.e. including CLIP and/or CNIP, newly 
assigned call id for the second incoming call, and 'CS call setup' call status). 

Call waiting acceptance: The call waiting acceptance shall always use procedure 'Call waiting acceptance (from PP to 
FP)' of clause 7.4.3.5.6, with the following modification: 

• call statuses 'CS call hold' for the former active call, and 'CS call connect' for the newly accepted waiting call, 
although they shall still be sent, and sent in this order, may be sent by the FP not at the exact times when the 
corresponding events occurred in the network. 

The FP shall use its best endeavour to translate the call waiting acceptance into network directed commands. 
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PP 



FP 



(^ External call 1 (with call id 1) currently in use by PP 

Call waiting indication 

CC-INFO 




« SIGNAL value = 'call waiting tone' = '07'H 

« CALLING PARTY NUMBER, < Calling Party Address = 'c 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value 

< id type = 'Line identifier', subtype='line type information'. 

< id type/subtype = 'Call identifier', value = 'waiting call id' 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 

Call waiting acceptance 

CC-INFO 



illing number' > » 

waiting call line id' > 
value = '1y'B> 
02'H> 



« MULTI-KEYPAD, info = '1C 35'H » 

« CALL-INFORMATION, 
< id type = 'Call identifier', value = 'waiting call id' = '02'H> 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' 

» 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call connect' : 



Off-hook CLIP 



Translation of the 'CW 
acceptance' into a 
network directed 
command 



Immediate sending 
of call statuses, 

independently of any 
network feedback 
(success assumed) 



Figure 29: Call waiting acceptance within an 'off-hook CLIP enabled DCIBS' line 

Call waiting rejection: The call waiting rejection shall always use procedure 'Call waiting rejection (from PP to FP)' of 
clause 7.4.3.5.7. 

NOTE: The call status 'CS idle' to the PP indicates that the waiting call context on PP side has to be deleted, but 
may not be related to the time when the waiting call indication from the network terminates. 

The FP shall use its best endeavour to translate the call waiting rejection into network directed commands if this is 
possible. 

7.4.3.1 0.3.3.3 Call toggle within an off-hook CLIP enabled DCIBS line 

This procedure applies to a 'Off-hook CLIP enabled DCIBS' line with two existing calls, and a PP busy with one of the 
calls on that line. 

Call toggle request. The call toggle request shall always use procedure 'Call toggle (external or internal)' of 
clause 7.4.3.5.3, with the following modification: 

• call statuses 'CS call hold' for the former active call, and 'CS call connect' for the newly active call, although 
they shall still be sent, and sent in this order, may be sent by the FP not at the exact times when the 
corresponding events occurred in the network. 

The FP shall use its best endeavour to translate the call toggle request into network directed commands. 
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7.4.3.10.3.3.4 Active call release with replacement within an off-hook CLIP enabled DCIBS line 

Active call release request with replacement. This request shall always use procedure 'Active call release with 
replacement (from PP to FP)' of clause 7.4.3.5.12, with the following modification: 

• call statuses 'CS idle' for the former active call, and 'CS call connect' for the newly active call, although they 
shall still be sent, and sent in this order, may be sent by the FP not at the exact times when the call replacement 
occurs in the network. 

The FP shall use its best endeavour to translate the "active call release with replacement" request into network directed 
commands. 

7.4.3.1 0.3.4 Parallel calls away from an off-hook CLIP enabled DCIBS line 

This procedure applies to a handset involved in call 'a' on line A ('Off-hook CLIP enabled DCIBS' line) and leaving this 
call and line in order to: 

1) either place a new call on another line B (outgoing parallel call initiation); 

connect an existing call on another line B (call toggle, call waiting acceptance); or 

connect an existing call on another line B while releasing the active call (active call release with replacement). 



Table 20: Call status to be sent for call a 



Procedure 


Clause 


Message from FP to PP 


Single call use case 

Call a active on line A 


Two calls use cases 

Call a active on line A 
Call b on-hold on line A 


Outgoing parallel call initiation (external or internal) 


7.4.3.5.1 


CS call hold (call a) 


CS call hold (call a) (note 1) 


Call toggle (external or internal) 


7.4.3.5.3 


CS call hold (call a) 


CS call hold (call a) (note 1) 


Call waiting acceptance (from PP to FP) 


7.4.3.5.6 


CS call hold (call a) 


CS call hold (call a) (note 1) 


Active call release with replacement (from PP to FP) 


7.4.3.5.12 


CC-RELEASE 


CS idle (call a), or CS call 
hold (call a) (note 2) 


NOTE 1 : After the handset has left the line, both calls a and b shall be considered on-hold from the PP and user 

perspective, although call a may remain active (but not currently in use) on network side; in that case, the 
FP should play an on-hold music toward the network in order to inform the remote party. 

NOTE 2: The FP may not be able to perform a partial release towards the network for call a; in that case the FP shall 
still partially fulfil the request: 'CS call hold' shall be sent for call a with call status reason 'control code failed'. 
Note that the overall result of the request in that case is similar to a call toggle (but with a 'call status reason' 
sent for call a due to the partial failure). 



7.4.3.1 0.3.5 Parallel calls towards an off-hook CLIP enabled DCIBS line 

This procedure applies to an 'Off-hook CLIP enabled DCIBS' line (line A), and to a handset involved in a call on 
another line, or in an internal call, and leaving this line or internal call in order to be connected to call a on line A. 

NOTE 1 : Call 'a' may be created by the handset, or be a previouly existing call owned by the handset. 

NOTE 2: There may be or not another call 'b' on line A. 
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Table 21 : Call status to be sent to the handset for call a 



Procedure 


Clause 


Message from FP to PP 

Call a and b are both on targeted line A 
Call a is the call targeted by the procedure 


rroceaures aaaing a can (new active can; 10 me 
nanasei 




Single call use case 

Call a to be created 


Two calls use cases 

Call a to be created 

Call b on-hold (see note 1) 


Outgoing parallel call initiation (external or internal) 


7.4.3.5.1 


CS call connect (call a) 
See notes 2 and 3 


CS call connect (call a) 
See notes 2 and 4 


Call waiting acceptance (from PP to FP) 


7.4.3.5.6 


Active call release with replacement (by call waiting) 


7.4.3.5.12 


Procedures changing the active call on the 
handset 




Single call use case 

Call a on-hold (note 1) 


Two calls use cases 

Call a and b on-hold (note 1 ) 


Call toggle (external or internal) 


7.4.3.5.3 


CS call connect (call a) 
See note 5 


Active call release with replacement (by call on-hold) 


7.4.3.5.12 


NOTE 1 : The indicated status is from handset point of view here. On network side, the call indicated as on-hold to the 
PP may remain active. 

NOTE 2: The FP may send the 'CS call connect' call status before end-to-end connection (e.g. as soon as it receives 
the first keypad information), as it may have no information from the network (see also clause 7.4.3.10.3.1). 

NOTE 3: Procedures of clauses 7.4.3.5.1 , 7.4.3.5.6 and 7.4.3.5.1 2 are used here for a first call on line A (outgoing or 
incoming). 

NOTE 4: An appropriate translation of the request into network directed commands shall be carried out. 
NOTE 5: If call a was active on network side, the FP shall switch off the on-hold music if used, and no translation into 
the network shall be used. Otherwise, note 4 applies. 



7.4.3.10.3.6 Call transfer 

This procedure applies to PP sending a 'call transfer request' in order to transfer an external call (announced or 
unannounced) on a DCIBS line to another PP. 

The procedure 'Call transfer' of clause 7.4.3.6 applies, with the following modifications: 

• If there are two calls on the DCIBS line, the FP should refuse the transfer of one of these calls, and send a 
negative acknowledgment. 

NOTE: If there are two calls on a DCIBS lines, both calls should be transferred, as they can only be handled by a 
single PP (single call line). However the user may not want to transfer both calls, and the transfer of two 
calls is not defined. 

• For a waiting call on the DCIBS line after a call transfer to a PP not attached to that line, the call waiting 
indication should however be sent that PP, as if it was attached to the line. 

7.4.3.1 0.3.7 3-party conference call 

This procedure applies to PP involved in two parallel calls, one of them being the active call, and one of them at least 
being on line A (an 'Off-hook CLIP enabled DCIBS' line), and sending a conference call request. 

The procedure '3-party conference with established external and/or internal calls' of clause 7.4.3.7 applies, with the 
modifications described in table 22. 



Table 22: Call statuses following a conference call request 



Procedure 


Clause 


Message from FP to PP 

The conference call is established from call a and b 
Call a at least is on line A 






Call a and b on line A 


Call a on line A 

Call b on another line, or 

internal 


3-party Conference with established internal and 
external calls 


7.4.3.7 


CS idle (call b) and 

CS conf. connect (call a) 

(notes 1, 2, 3 and 4) 


CS idle (call b) and 
CS conf. connect (call a) 
(note 2) 


Unsuccessful 3-party conference call 


7.4.3.7.1 


CS call connect 
(previously active call) 
(note 5) 


FP originating failure 

CS call connect (previously 

active call) 
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Procedure 


Clause 


Message from FP to PP 

The conference call is established from call a and b 
Call a at least is on line A 


3-party conference call release 

(Conference call changed into a regular two-end call, 

or fully released) 


7.4.3.7.2 


Not applicable for a 
remote party hang-up. 
Otherwise (PP hang-up): 
CS idle (call a) (note 2) 


Applicable for a remote party 
hang-up at the handset 
initiative (see subsection 
'Release of one of the parties 
from the 3PTY conference 
initiating PP') 


NOTE 1 : Call statuses 'CS idle' for the released call, and 'CS conference connect' for the new conference, shall still be 
sent by the FP, and sent in this order, but may be sent not at the exact time when the conference is established 
in the network. 

NOTE 2: The hypothesis here is that call id of call a was reused for the conference. 

NOTE 3: An appropriate translation of the request into network directed commands shall be carried out. 

NOTE 4: As there is a single PP involved in this use case, no call id update is needed. 

NOTE 5: The conference call establishment failed in the network. The failure may not be detected by the FP. In that case 
no call status shall be sent back to the PP. 



7.4.3.1 0.4 Use of transparent commands on DCIBS lines (Basic or Off-hook CLIP enabled) 
or any other line 

This procedure applies to a PP using transparent commands as keypad information towards the FP in order to handle 
parallel calls on a DCIBS line or any other type of line. 

NOTE 1: DCIBS lines are known to be manageable through the use of transparent commands. 

NOTE 2: The feature 'Handling of lines where second calls are signalled in-band' lines discourages the use of 

transparent commands with off-hook CLIP enabled DCIBS lines. But transparent commands are the only 
way to handle double calls on basic DCIBS lines. 

NOTE 3: Transparent commands are especially useful for GAP or Part 1 PPs, and should not be used by Part 3 PPs, 
unless the user directly enters theses commands on the keypad (e.g. instead of using Part 3 dedicated 
menus). The use of transparent commands towards a line (especially a non DCIBS line) is not guaranteed 
to have any effect in general. 

Transparent commands. Keypad information sent to the FP when no call is currently processed with the 'Common 
parallel call procedures'. Transparent commands consist in keypad information sent in one or several 
«MULTI-KEYPAD» information element sent in as many {CC-INFO} messages. 

NOTE 4: Keypad information sent by a Part 3 PP may also be sent as part of the 'Common parallel call procedures' 
when a call is being processed. Such keypad information is not considered as transparent command. 

EXAMPLE: The digits of the called number sent as part of the 'outgoing parallel call initiation', being part of a 
'common parallel call' procedure, are not considered as a transparent commands, although they are 
forwarded to the network. 

Transparent commands shall be sent to the FP with the call id of the currently active call (by definition, no call is 
currently being processed with the 'Common parallel call procedures' when a transparent command is sent). 

As a result, the used {CC-INFO} messages shall always contain a «C ALL-INFO RMATION» IE. 

When the currently active call is on a DCIBS line, the FP shall not translate/modify the transparent commands received 
from the PP when relaying them to the (PSTN) network. 
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PP 



Transparent 
outgoing 
parallel call 
initiation 




Existing call 1 with call id 1 on PSTN line 
Handset busy with call 1 

CC-INFO 




FP 



« MULTI-KEYPAD, < Keypad info = '15' H > » 

« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = '01 'H > » 

CC-INFO 



7.4.4 
7.4.4.1 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 

« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = '01 'H > » 



Figure 30: Example of use of transparent commands (with call id of current call) 

Handling of single call services 
Control messages 



The following control codes shall be transmitted as keypad information in {CC-INFO} messages and shall trigger the 
corresponding actions in the FP. 



7.4.4.1.1 



Call deflection control messages 
Table 23: Control messages for control of single call services 



Procedure 


Control message 


Direction 


PT Status 


FT Status 


Call deflection (to internal) 


1 CH 39H 1 7H + terminal id number 


PP to FP 


C2301 


C2302 


Call deflection (to external) 


1CH 39H 15H + number 


PP to FP 


C2301 


C2302 


C2301 : If PT implements call deflection feature [NG1 .N.1 1] THEN "M" ELSE "I". 

C2302: If FT implements call deflection feature [NG1 .N.1 1 ] THEN "M" ELSE minimum requirement of 

"negative acknowledgement" with call status reason 'control code not supported' (see clause 7.4.3.4). 



Call deflection procedure for internal and external calls is detailed in clause 7.4.4.2. 



7.4.4.2 Call deflection 

When implementing the feature, the FP shall set bit of the "Extended higher layer capabilities (part 2)" 
(see EN 300 175-5 [5], clause F.3). 

The call deflection service enables the user to respond to an incoming call (external or internal) by requesting 
redirection of this call to another number specified in the response. The call deflection service can only be requested 
before the connection is established by the user, i.e. in response to the incoming call during the period that the user is 
being alerted of the call (see TS 122 072 [i.16]). 

Call deflection request. In order to deflect a call with "CS call setup" call status, the PP shall send a 'call deflection 
request' consisting in the control code 1CH as keypad information in a {CC-INFO} message, followed by 39H and by 
the deflected-to telephone number (external or internal). The deflected-to telephone number shall be preceded by 15H if 
external or by 17H if internal. 

NOTE 1 : A first incoming call, or a call waiting can be deflected. 

As a result of successful call deflection to an internal number, the incoming call (external or internal) shall only 
presented to the deflected-to terminal. For an external incoming call, the deflected-to terminal may be attached to the 
line of the call (it continues presenting the call, but alone) or not attached to that line (it starts presenting the call). 

As a result of successful call deflection to an external number, the incoming call (external or internal) shall no longer be 
presented to any PP. 
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It is recommended that the deflected-to telephone number is pre-configured (in the handset) before using this service. 
The PP related procedures to pre-program and display the deflected-to number is out of the scope of this procedure. 

If a user sends a call deflection request, and the deflected-to telephone number is internal, the FP shall: 

• present the incoming call to the "deflected-to" PP only (designated by the number in the request); 

• release the call on all other PP(s) that received the incoming call. 

If a user sends a call deflection request, and the deflected-to telephone number is external, the FP shall relay the service 
request to the network: 

• if the service can be provided, the FP shall release the incoming call on all PPs that received the incoming call; 

• if the service cannot be provided, the FP shall send a negative acknowledgment as described in clause 7.4.3.4 
(call status of the incoming call 'CS call setup' re-sent, along with call status reason 'control code failed'). The 
FP shall proceed further with the incoming call. 

NOTE 2: There are various mechanisms for the FP to be aware that the service cannot be provided by the network. 
For example by getting a negative answer from the network when invoking the service or by 
configuration of the line. However these mechanisms are out of the scope of the present document. 

On the FP side, only the first call deflection request shall be taken into account. Possible further requests concerning 
this call and coming from the same or other PPs shall be ignored. 
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PP 



FP 



Network 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for exte 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value ='CS call setup' > 

CC-ALERTING 



call deflection request 

CC-INFO 



« MULTI-KEYPAD, '1C 39 15'H + number 
« CALL-INFORMATION, 

< Identifier type/subtype = Call identifier' > 

< Identifier value = '01 'H > 



nal calls' : 



if the incoming call 
> is external 



if request accepted: 



CC-RELEASE 




call deflection activation 
to 'number' 




CC-RELEASE-COM 



if request rejected (example): 

CC-INFO 



If user 
picks-up 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value |= '01 'H > 



< id type/subtype ■ 

< id type/subtype ■ 



'Call status', value ■■ 



)S call setup> 



Call status reason', value = 'control code failed'> 



CC-CONNECT 



J 



Figure 31 : Call deflection invocation when the deflected-to party is external? 



ETSI 



112 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



PP1 



FP 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for exte 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information' 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value ='CS call setup' > 
» 

CC-ALERTING 



call deflection request 

CC-INFO 



« MULTI-KEYPAD, '1C 39 17'H + number 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 



PP2 



nal calls' 



if the incoming call 
is external 



if request accepted: 



CC-SETUP 



« CALLING PARTY NUMBER» (see note 5) 



if the incoming call 
is external 



« CALL-INFORMATION, 

< Id type = 'Line identifier' > 

< Id subtype = 'Line identifier for external 

< Identifier value = u > 

< Id type = 'Line identifier' > 

< Id subtype = 'line type information^ 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 



CC-ALERTING 



c; ills' 



CC-RELEASE 



CC-RELEASE-COM 



if request rejected (example): 

CC-INFO 



If user 
picks-up 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value 

< id type/subtype = 'Call status', value = 

< id type/subtype = 'Call status reason', 

» 

CC-CONNECT 



= '01 'H > 

CS call setup> 

ralue = 'control code failed'> 



Figure 32: Call deflection invocation when the deflected-to party is internal 



NOTE 3: The Call Control message sequences in figures 31 and 32 should be understood as examples. The real 

sequences may also contain different Call Control messages or Call Control messages in another order or 
Call Control messages with other contents. 
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NOTE 4: «CALLING PARTY NUMBER» is the deflected (remote) party calling party number. It could also be 
sent in a {CC-INFO} message. 

7.4.5 Line identification 

7.4.5.1 Line identification general requirements 

Line identifiers are used to identify the line on which an external call (incoming or outgoing) is made. Furthermore it is 
used by the FP to inform the PP about the line type (i.e.: 'network delay type', 'second call type', etc.) of the selected 
line. 

When the "Multiple line" feature is also implemented, line identifiers allow to enhance the handling of parallel calls in 
the "Common parallel call procedures" feature. However, when the "Line identification" feature is implemented, line 
identifiers shall be sent even if there is only one line in the system. Furthermore, if there are several lines in the system 
(meaning that the "Multiple line" feature is also implemented), the line identifiers shall be used also for PPs attached to 
only one line. 

Typically, a FP would use line identifiers in the 0..n interval, where 'n+1' represents the number of lines it handles. 

NOTE: A FP can support up to 127 lines. 

For a first or parallel outgoing external call, the line identifier selected by the PP shall be sent to the FP (see 
clauses 7.4.5.2 and 7.4.3.5.1). However, if the PP wishes to use FP-managed line selection' (see clause 7.4.5.2.4), it 
shall send the special line id value 'None' instead (see clause 3.1). In both cases ('PP line selection' or FP-managed line 
selection') the FP shall send back the line id it selected for the call to the PP. 

This line identifier sent back by the FP shall also include the line type information included in the line identifier of 
subtype Line type information', with at least the following flags: 

• 'network delay type', indicating whether the delay of the network (to which the selected line is attached to) is 
'significant' (e.g. VoIP based network) or 'low' (e.g. PSTN/ISDN based network); 

• 'second call type', indicating whether the selected line in an 'double call with in-band signalling' line or not. 

For a first or parallel incoming external call, the line identifier value and line type information of the call (with at least 
the same flags as above) shall be notified from FP to PP (see clauses 7.4.5.3 and 7.4.3.5.2). 

The present document only specifies a single mandatory line id notification per call (either from PP to FP or from FP to 
PP); However, in order to ease implementation, and although it is no longer mentioned elsewhere in the present 
document, both parties are allowed to send the line id again in messages following this notification. But, for the sake of 
interoperability, the party receiving these redundant line id values should ignore them. 

7.4.5.2 Line identification for external outgoing calls 

7.4.5.2.1 General line identification requirements for external outgoing calls 

For outgoing calls, the "Line identification" feature enables a PP to select the line on which the call has to be placed. 
For each outgoing call, the PP shall either: 

• select a specific line to place the call; or 

• select line identifier 'None' to let the FP manage the line selection for this call. 

Both modes shall be available for the user on PP side. 

NOTE 1 : The intention is to avoid implementations where PP would send only "None" line identifier in front of a 
FP supporting several lines. 

If the PP has selected a specific line, it shall not make a different selection in a subsequent message. The PP shall not 
select a line it is not attached to (in that case the FP shall disconnect the call). 
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If the PP uses line identifier 'None', the FP shall select a line on behalf of the PP. Whether the line is selected by the PP 
or by the FP, the FP shall send back to the PP the line identifier for the selected line where the call will be placed 
together with the line type information (see clause 7.4.5.1). 

This procedure applies to all external outgoing calls (first or parallel). In the case of a parallel call, it only applies if the 
feature entitled "Common multiple call procedures" is also implemented. In that case, relevant procedures are described 
there. 

Exception case: if the PP has selected a specific line in order to place an emergency call, the FP may consider that it 
has received a 'None' line identifier and use FP managed line selection instead, to process the call further. This 
exception shall not be used for non-emergency calls. 

NOTE 2: This rule allows the FP to select a more appropriate line if the PP specified line is not suitable (e.g. busy, 
out of order, etc.) when an emergency number is dialled. 

The line identifier information shall be sent using one of the following methods: 

• For Part 3 PPs, included in a « CALL INFORM ATION» information element sent in the {CC-SETUP} 
message or in a {CC-INFO} message. 

• For GAP PPs and Part 1 PPs, included in a « MULTI-KEYPAD» information element sent in a 
{CC-INFO} message. This method shall only be used if the line identifier is in the interval 0..9. If this method 
is used, the line identifier information shall consist in the pound key ("#") character ('23'H) followed by the 
line identifier digit, I A5 -coded on a single octet. 

7.4.5.2.2 Line identification for a first external outgoing call using «CALL 

INFORMATIONS 

This procedures applies to the Part 3 FP and to a Part 3 PP effectively sending a line identifier for a first external 
outgoing call. This procedure uses the «CALL-INFORMATION» information element. 

When using the present procedure, and as an addition to procedure "Outgoing call request" of GAP [12], clause 8.2, a 
« CALL INFORMATION» IE shall be used for conveying the line identifier information. This IE shall be sent: 

• either included in the {CC-SETUP} message; or 

• included in a subsequent {CC-INFO} message, together with the first called number digit at the latest. 

If not using the present procedure for a first outgoing call, a Part 3 PP shall use procedure "FP managed line selection 
for a first external outgoing call" of clause 7.4.5.2.4 instead. 



Table 24: Values used within the {CC-SETUP} message 
when the « CALL-INFORMATION» method is used for conveying the line identifier information 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Call-information» 


identifier type> 





Code for 'Line identifier' identifier type 


identifier subtype> 





Code for 'Line identifier for external 
calls' subtype 


identifier value> 


All 


The line identifier value itself 



The FP shall confirm the line selection of the PP by sending back a «CALL INFORMATION» IE conveying the line 
identifier information with the line identifier value and the line type information. This IE shall be sent: 

• for a 'non early { CC-CONNECT } ' implementation of the FP: 

either included in the { CC-SETUP -ACK} message, if sent, and if the line id value was sent in the 
{CC-SETUP}; or 

included in the {CC-CALL-PROC} message, if sent, and sent early enough; or 

included in a {CC-INFO} message sent after the first CC message from the FP and before the 
{CC-CONNECT}. In that case, the {CC-INFO} message contains a call id but does not bear any call 
status; or 
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in specific cases, in the {CC-CONNECT} itself. This is only allowed in the present document for 
implicit or explicit call intrusion (and whether PP line selection occurs in {CC-SETUP} or not). 

• for an 'early { CC-CONNECT } ' implementation of the FP: 

either included in the {CC-CONNECT} message; or 

in a {CC-INFO} message following the {CC-CONNECT} and sent before call status 'CS call connect' or 
'CS conference connect'; or 

in specific cases, together with the 'CS call connect' or 'CS conference connect' call status. This is only 
allowed in the present document for implicit or explicit call intrusion (and whether PP line selection 
occurs in the {CC-SETUP} or not). 

The FP shall not use this confirmation to change the line to be used. If the selected line cannot be used, the FP shall use 
procedure "Busy system or line notification" of clause 7.4.8.3 in order to disconnect the call. 



Table 25: Values used within the {CC-SETUP_ACK}, {CC_CALL_PROC}, {CCJNFO} 
or {CCCONNECT} message used for confirming the line selection of the PP 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Call-information» 


identifier type> 





Code for 'Line identifier' identifier type 


identifier subtype> 





Code for 'Line identifier for external 
calls' subtype 


identifier value> 


All 


The line identifier value itself 


identifier type> 





Code for 'Line identifier' identifier type 


identifier subtype> 


5H 


Code for 'Line type information' 
subtype 


identifier value> 


'00'B 
'01 'B 
'10'B 
■1 1'B 


Regular line with low delay 
Regular line with significant delay 
DCIBS line with low delay 
DCIBS line with significant delay 
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PP 



FP 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

» 



CC-SETUP-ACK 



Store call in call table and 
assign call id 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« MULTI-KEYPAD. < KevDad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 



start outgoing call 
towards peer party 
on line 'u' 



Figure 33: Line identification in {CC-SETUP} 
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PP 



FP 



CC-SETUP 



CC-SETUP-ACK 



Store call in call table and 
assign call id 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

» 

CC-INFO 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 
» 

CC-INFO 



« MULTI-KEYPAD. < KevDad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

» 



start outgoing call 
towards peer party 
on line 'u' 



Figure 34: Line identification in {CC-INFO} 
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PP 



FP 



CC-SETUP 



CC-SETUP-ACK 



Store call in call table and 
assign call id 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« MULTI-KEYPAD. < KevDad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

» 

CC-CALL PROC 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call proc' > 



Figure 35: Line identification together with called number in {CC-INFO} 



start outgoing call 
towards peer party 
on line 'u' 



NOTE: The Call Control message sequence in figures 33, 34 and 35 should be understood as an example. The 

real sequences may also contain different Call Control messages, Call Control messages in different order 
or Call Control messages with other contents. 



7.4.5.2.3 Backward compatible line identification for a first external outgoing call using « 

MULTI-KEYPAD» IE 

This procedure applies to the FP and a GAP or Part 1 PP, and allows the PP to send a line identifier for a first external 
outgoing call in a backward compatible way (i.e. using the «MULTI-KEYPAD» IE). 

When using the present procedure, a « MULTI-KEYPAD» information element shall be used for conveying the line 
identifier information. This information element shall be included in a {CC-INFO} message, as described in procedure 
"Sending keypad information" of GAP [12], clause 8.10. 

When the present procedure is used, the FP shall NOT confirm the line selection of the GAP or Part 1 PP (line selection 
confirmation is used for Part 3 PPs and is described in clause 7.4.5.2.2). 

Table 26 shall be considered. 

NOTE 1 : The «MULTI-KEYPAD» information element used may contain (partial or complete) called party 
number information. See clause C. 2.2. 2.2 for an example. 
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Table 26: Values used within the {CC-INFO} message 
when the «MULTI-KEYPAD» method is used for conveying the line identifier information 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Multi-keypad» 


<Keypad info 


23H 


Code for the pound key ('#') used for 
introducing the line identifier 


30H - 39H 


The line identifier itself 



NOTE 2: The present procedure cannot be used for Part 3 PPs. When similar keypad information is sent by a Part 3 
PP to the FP, the FP forwards such keypad information unchanged to the network. 

When receiving a '#k keypad information (with k e [0..9]) from a GAP or Part 1 PP, the FP shall not automatically infer 
that the current procedure is used. The user intention could be to rely on the FP for selecting the line (using 'Backwards 
compatible FP managed line selection' of clause 7.4.5.2.4.2), and to then send a (possibly network-specific) code 
beginning with '#k...' to the network. The FP can use several hints like the following ones, in order to disambiguate the 
user intention: 

• existence or not of a line numbered 'k in the DECT system; 

• existence or not of the entered code for the line the FP would select in case of FP managed line selection. 



PP 

attached to line u e 1 ..9 



FP 



Network 



CC-SETUP 



CC-SETUP-ACK 



CC-INFO 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 



Use of line u 
for calling 
'called number' 




Figure 36: Line identification for a first external outgoing call, 
using the « MULTI-KEYPAD» method 



NOTE 3: See also clause C.2. 2.2.2 for a variant of figure 36 use case. 



7.4.5.2.4 FP managed line selection for a first external outgoing call 



7.4.5.2.4.1 FP managed line selection for a first external outgoing call from a Part 3 PP 

This procedures applies to the Part 3 FP and a Part 3 PP making a first external outgoing call. It allows the PP not to 
specify any line identifier for this new call. 

In that case, the line selection is said to be "FP-managed". 

When using the present procedure, and as an addition to procedure "Outgoing call request" of GAP [12], clause 8.2, a 
« CALL INFOPvMATION» IE shall be used for conveying the special line id value 'None' (see clause 3.1). This 
value shall be sent instead of a regular line id, at any possible time and in any possible location for sending a regular 
line-id as described in clause 7.4.5.2.2, i.e.: 

• included in the {CC-SETUP} message; or 

• included in a subsequent {CC-INFO} message, together with the first called number digit at the latest. 
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A FP implementing this procedure shall therefore always be prepared to possibly select a line on behalf of the PP. 

NOTE 1 : The PP can therefore allow its user not to select any line (either on a call-by-call basis, or permanently by 
configuration). 

A PP attached to only one line (e.g. registered to a FP with only one line) may use the present procedure. 

If a Part 3 PP uses the special line identifier value 'None', in order to use "FP managed line selection", it shall not select 
a line in a subsequent message. 

When receiving 'None', the FP shall select a line on behalf of the PP. The FP shall then notify the selected line identifier 
value and line type information to the PP. This notification shall be sent, as described on figures 37, 38, 39 and 40: 

• for a 'non early { CC-CONNECT } ' implementation of the FP: 

either included in the {CC-SETUP-ACK} message, if sent, and if the 'None' value was sent in the 
{CC-SETUP}; 

or included in the { CC-CALL-PROC } message, if sent, and sent early enough; 

or included in a {CC-INFO} message sent after the first CC message from the FP and before the 
{CC-CONNECT}. In that case, the {CC-INFO} message contains a call id but does not bear any call 
status; 

or, in specific cases, in the {CC-CONNECT} itself. This is only allowed in the present document for 
implicit or explicit call intrusion (and whether 'None' is sent in {CC-SETUP} or not). 

• for an 'early { CC-CONNECT } ' implementation of the FP: 

either included in the {CC-CONNECT} message; or 

in a {CC-INFO} message following the {CC-CONNECT} and sent before 'CS call connect' or 'CS 
conference connect' call status; or 

in specific cases, together with the 'CS call connect' or 'CS conference connect' call status. This is only 
allowed in the present document for implicit or explicit call intrusion (and whether 'None' is sent in the 
{CC-SETUP} or not). 

The FP may defer line selection and notification until it has all the information needed to make the selection (in 
particular, in some system configurations, the selected line could depend on the dialled number). 



Table 27: Values used within the {CC-SETUP_ACK}, {CC_CALL_PROC}, {CCJNFO}. or 
{CC CONNECT} message used for conveying the line identifier value and line type information 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Call-information» 


identifier type> 





Code for 'Line identifier' identifier type 


identifier subtype> 





Code for 'Line identifier for external 
calls' subtype 


identifier value> 


All 


The line identifier value itself 


identifier type> 





Code for 'Line identifier' identifier type 


identifier subtype> 


5H 


Code for 'Line type information' 
subtype 


identifier value> 


'00'B 
'01 'B 
'10'B 
■1 1'B 


Regular line with low delay 
Regular line with significant delay 
DCIBS line with low delay 
DCIBS line with significant delay 



NOTE 2: Some kind of "FP managed line selection" may also be used for "Call intrusion" (see clause 7.4.3.8) and 
is used for "Headset management" (see clause 7.4.16.2.2). 
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PP 



FP 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = 'None' > 

» 

CC-SETUP-ACK 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

» 



Store call in call 
table and assign 
call id 



Selects u among 
lines attached to PP 



The FP sends the line id 
- also if the PP is attached to 
only one line 

or if there is only one line in 
the system 



start outgoing call 
towards peer party 
on line 'u' 



Figure 37: FP-managed line selection in {CC-SETUP-ACK} (together with call id assignment) 
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PP 



FP 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = 'None' > 

CC-SETUP-ACK 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« MULTI-KEYPAD. < KevDad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 



CC-CALL-PROC 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call proc' > 



Figure 38: FP-managed line selection deferred to {CC-CALL-PROC} 



Store call in call 
table and assign 
call id 



start outgoing call 
towards peer party 
on line 'u' 



Selects u among 
lines attached to PP 



The FP sends the line id 
- also if the PP is attached to 
only one line 

or if there is only one line in 
the system 



NOTE 3: This can be used if the line id selected by the FP would depend from the called number, the FP may wait 
until the called number is received (partly or completely) before it notifies the line id used. 
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PP 



FP 



CC-SETUP 



CC-SETUP-ACK 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« MULTI-KEYPAD. < KevDad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = 'None' > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

CC-CALL-PROC 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call proc' > 

» 



Figure 39: Deferred use of 'None', together with called number 



Store call in call 
table and assign 
call id 



Selects u among 
lines attached to PP 



Notify PP of the 
chosen line-id and 
starts outgoing call 
towards peer party 
on line "u' 
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PP 



CC-SETUP 



FP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = 'None' > 



» 



CC-CONNECT 



Store call in call table 
and assign call id 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 



Early CC 



< Identifier value = '03'H > 



message used 



CS call c 



jnnect call status 



» 



CC-INFO 



not yet re ached 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 



Figure 40: Example of use with an early {CC-CONNECT} implementation 



CONNECT 



7.4.5.2.4.2 Backwards compatible FP managed line selection for a first external outgoing call 

This procedures applies to a Part 3 FP in front of a GAP or Part 1 PP making a first external outgoing call. 

For a given call, the default behaviour of a GAP or Part 1 PP making a first external outgoing call is to send no line 
identifier. 

A Part 3 FP implementing this procedure shall wait for the first keypad information received from the GAP or Part 1 
PP. If the keypad information is different from '23'H ('#' character), it shall infer that FP managed line selection is used, 
and shall therefore select a line on behalf of the PP. 

NOTE: This corresponds to the classical way of using a GAP or Part 1 PP. 

The FP may notify back the user of the PP of the used line identifier using a «DISPLAY» information element. 
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GAP or Part 1 PP 

attached at least to 
line u 



FP 



Network 



CC-SETUP 



CC-SETUP-ACK 



CC-INFO 



« MULTI -KEYPAD, < Keypad info = 'called number' > » 



Selects u among 
lines attached to PP 



CC-INFO 

+ 

<< DISPLAY, info = "Line u is used"> >> 



Use of line u 
for calling 
'called number' 




Figure 41 : Backward compatible FP managed line selection 



7.4.5.3 Line identification for external incoming call 

7.4.5.3.1 General line identification requirements for external incoming calls 

For incoming calls, the "Line identification" feature enables the FP to notify the PP of the line on which the incoming 
call was received. 

NOTE: The current general procedure applies to all external incoming calls (first incoming call or waiting call). 
In the case of a waiting call, it applies conditionally to the implementation of the feature entitled 
"Common multiple call procedures". 

For incoming calls, the line identifier information (including the 'line type information') shall always be sent included in 
a « CALL INFORM ATION» information element, as follows: 

• For a first incoming call, it shall be sent in the {CC-SETUP} message, as described in clause 7.4.5.3.2. 

• For a waiting call, it shall be sent in every {CC-INFO} message used for notifying the waiting call, as 
described in clause 7.4.3.5.2. 

7.4.5.3.2 Line identification for a first external incoming call 

For incoming calls, the "Line identification" feature enables the FP to notify the PP of the line identifier of the line on 
which the incoming call arrived. Furthermore it is used by the FP to inform the PP about the 'line type information' of 
the selected line. 

A line identifier for an incoming call shall be sent from FP to PP in a «CALL INFORMATION» information 
element in the {CC-SETUP}message, as an addition to GAP [12], clause 8.12, "Incoming call request". 

The FP shall notify the line identifier used even if there is only one line in the system, and even if the PP is attached to 
only one line. 
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PP 

attached at least to 
line u 



CC-SETUP 

< 

« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '01 'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value ='CS call setup' > 

» 

CC-ALERTING 

► 



Figure 42: Line identification for a first external incoming call 



7.4.6 Call identification 
7.4.6.1 Call identification general requirements 

The "Call identification" feature handles: 

• The definition of a call identifier (or call id) by the FP for each call, and the use of this call id in both 
directions to identify the call a received message belongs to. 

• The sending from FP to PP of a call status - at some points of the call progression- and in some cases of an 
associated call status reason (see clause 7.4.6.4). 

Call identifiers are used to identify all ongoing calls in a DECT system, internal or external. They allow to enhance the 
"Parallel call" and "Multiple call" features. More specifically: 

• Call identifiers allow to properly handle PPs with more than 2 call instances, especially for all double call 
related procedures (see clause 7.4.3.5). 

• Even for PPs with only 2 call instances, call identifiers allow to properly handle asynchronous messages (for 
example a call toggle from the PP crossing a call release from the FP). 

Call identifiers are assigned by the FP and are uniquely defined at DECT system-wide. 

NOTE 1 : As described below, there is one exception to this general principle: for external incoming call, it is 
allowed (but not required) to use different call ids for the different PPs before the call is established. 

System-wide call ids imply a one-to-one relationship between calls and call ids, and is therefore a two-fold requirement. 

On the one hand, a given call id shall not be used for different calls existing in the system at a given time. In other 
words, call identifiers shall NOT be PP specific (i.e. there shall never be two equal call identifiers for two different 
calls, even if the two calls are handled on 2 different PPs), nor line specific. 

On the other hand, a given call shall not be assigned several call ids in the system at a given time. In other words, a 
given call handled on different PPs shall have a unique call id for all PPs. This includes internal call, internal general 
call, and conference call with two PPs. 

NOTE 2: This includes use cases involving an internal call (or an internal general call), e.g. call transfer, call 
re-injection, etc. 



FP Network 

y^—- 1 

y Incoming call to line u 
from 'calling number' 
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NOTE 3: However, the FP may change the call id of a given call over time, through the use of a call id update. 

However, for an external incoming call, the FP is allowed to use a different call id for each PP before the call is 
established. At the end of incoming call establishment, all but one of these call ids shall be freed, and the remaining call 
id will become the system wide call id for the call. 

NOTE 4: The FP is not required to use different call id values: call ids on different PPs may have the same call id 
value, or not. 

NOTE 5: This includes external 'call waiting' use cases when the waiting call is presented to several PPs (incoming 
call on a line in 'multiple call' mode). 

NOTE 6: As described above this does not include internal incoming call (i.e. internal general call), even before the 
call is established. 

NOTE 7: The present document is sometimes referring to the call id of an incoming call. If the call is not yet 
established it is to be understood as the call id used for the considered PP. 




Figure 43: Calls identifiers are assigned by the FP and unique for the DECT System 

A call identifier is assigned each time a call is setup. In order to be usable for parallel/multiple calls, a call identifier 
shall be assigned also for the first call of a PP. 

The call identifier is freed on PP side at call release ('CS idle' received from the FP, or {CC-RELEASE-COM} sent or 
received by the PP). The PP shall no longer use the call id value except on FP's initiative. 

The call identifier is freed on FP side (and available for a further new call): 

• at call release if the call only involves one PP ('CS idle' sent to the PP, or {CC-RELEASE-COM} sent or 
received by the FP); 

• if several PPs are involved in the call (e.g. for call transfer, multiple call line, headset call interception, etc.), 
when the call does no longer exist in the system, i.e. at the time the call is released for the last PP involved in 
the call; 

• for an external incoming call, when one of the PPs picks up the call: call ids used for all other PPs (if different) 
shall be freed. 

The FP call identifier assignment method is left free to implementation. However, it is recommended to avoid possible 
conflicts of assignment when a call is being released while another one is being setup on the same PP (avoid re-using 
the first free call id). The FP may implement the "no re-use method" described below, which allows this. 

The "no re-use method" consists in assigning a call identifier to a new call in the interval [0, n]. Assignment starts or 
restarts at each time the system comes back to idle (all registered PPs are back to idle). For further calls, the rule 
"Assigned id = latest assigned id in time + 1 " applies. Latest assigned id may correspond to a still ongoing or an already 
terminated call. This method assumes that n is never reached. An easy implementation can be done by using n= 127 (127 
is the maximum call identifier length if no extension for the call identifier value is used). 
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The FP shall send a call identifier together with every call status sent to the PP, as specified in clause 7.4.6.4, and more 
generally, with all messages relating to the identified call (especially including the {CC-INFO} messages conveying the 
CLIP and the CNIP for a first incoming call -if a {CC-INFO} message is used- although there is no associated call 
status in this case). The first sending of the call identifier to the PP notifies the PP of the call id assignment for the call, 
as specified in clauses 7.4.6.2 (first outgoing call), 7.4.6.4.6 (first outgoing call using early CC-CONNECT 
implementation) and 7.4.6.3 (first incoming call), 7.4.3.5.1 (parallel outgoing call) and 7.4.3.5.2 (call waiting 
indication). 

The FP may notify the call id assignment while the call is being disconnected (i.e. together with call status 'CS call 
disconnecting'), as illustrated in clause 7.4.8.3, "Busy system or line notification". However, the FP shall not notify the 
call id assignment while releasing the call (i.e. together with call status 'CS idle'), as specified in clause 7.4.3.5.4, "Call 
release and call release rejection" 

The PP shall send call identifiers in {CC-INFO} messages as specified in clauses 7.4.6.4.5 (first outgoing call) and in 
7.4.3.5 (parallel calls), for all messages or requests relating to the identified call. As a result, once a call identifier is 
assigned, all the subsequent {CC-INFO} messages shall include a call identifier (i.e. Keypad, CLIP, CNIP, Signal, 
Display, etc.) 

Call identifiers shall be sent within the «CALL-INFORMATION» information element with <Identifier typo and 
identifier subtype> fields both equal to 'Call identifier'. It shall be sent if the sending party (PP or FP) implements the 
"Call identification" feature. The format to be used in all messages is shown in table 28. 



Table 28: Values used within any applicable CC message 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Call-information» 


identifier type> 


1 


Code for 'Call identifier' identifier type 


identifier subtype> 





Code for 'Call identifier' subtype 


identifier value> 


All 


The call identifier value itself 



NOTE 8: The "Call transfer", "3-party conference with established internal and/or external calls" and "Call 

intrusion" features also make use of call identifiers with a different identifier subtype> = 'Updated call 
identifier', for the purpose of updating the identifier of an existing call. This subtype is not used within the 
"Call identification" feature itself. 

When implementing the feature, the PP shall set the corresponding terminal capability bit. 

Definition of 'early {CC-CONNECT} implementations': It has been recognized that some existing implementations 
of GAP devices do not make use of the optional intermediate CC-States (e.g. Call Proceeding) for the first outgoing 
call, and rather send an early {CC-CONNECT}, thus using a simplified version of the state machine enough for the 
handling of PSTN calls in practice. In such implementations, the {CC-CONNECT} message from FP to PP is used as a 
way to require U-plane connection from the PP, even if the end to end connection with the remote party is not yet 
active. Such implementations avoid using the «PROGRESS INDICATOR» IE and minimize the number of 
exchanged CC messages. 

Such implementations, are allowed for Part 3 FPs, and are seamlessly integrated thanks to the 'Call status indication' 
procedure of clause 7.4.6.4 (see there for more details). 

Definition of 'Non early {CC-CONNECT} implementations': This is used for implementation that are not 'early 
CC-CONNECT' ones. 

7.4.6.2 Call identifier assignment on first outgoing call (FP to PP) 

The purpose of this procedure is to have the FP assign a unique call identifier for a first outgoing call, external or 
internal, and notify it back to the calling PP. 

In the case of an internal call, the FP shall assign a single call identifier for both PPs. 
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The assigned call identifier shall be notified back to the PP, by including a «CALL-INFORMATION» information 
element with <Call identifier> field value equal to the assigned call identifier in the first CC message sent back to the 
PP. More specifically, the call id assigned by the FP shall be sent first time to the PP as described below: 

• For "Non early {CC-CONNECTJ implementations" (see clause 7.4.6.1), the newly assigned call id for a first 
outgoing call shall be notified to the PP either: 

in { CC-SETUP- ACK } if sent; 

in { CC-C ALL-PROC } if sent as first CC message; 

in {CC- ALERTING} if sent as first CC message (should not occur very often); 

in {CC-CONNECT} if sent as first CC message (should not occur very often with a 'non-early' 
{CC-CONNECT} implementation). 

• For "Early { CC-CONNECT} implementations" (see clause 7.4.6.1), the newly assigned call id for a first 
outgoing call shall be notified to the PP in the {CC-CONNECT} message itself. 

NOTE: As described in clause 7.4.6.1, once the call id has been assigned and communicated to the PP, it is used 
in all subsequent messages (both directions) related to the same call. 

• The outgoing call procedure of GAP (see clauses 8.1 to 8.6 of EN 300 444 [12]) shall be used with the 
following modifications: 

the Information element «Call information» with the content described in table 28 (see clause 7.4.6.1) 
shall be added to the content of the {CC-SETUP- ACK}, { CC-C ALL-PROC } or {CC-CONNECT}, 
(depending on option) message with the rest of the content as described in EN 300 444 [12]; 

if the call identifier has not been sent in the {CC-SETUP- ACK}, { CC-C ALL-PROC } or 
{CC-CONNECT} message, then a dedicated {CC-INFO} message, FT to PT, shall be added to the 
procedure carrying the Information element «Call information» with the content described in table 28 
(see clause 7.4.6.1). 

PP FP 



CC-SETUP 








CC-SETUP-ACK 


Store call in call table 
and assign call id 




> 


« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = '03'H > 

CC-INFO 


* 

« MULTI-KEYPAD, < Keypad info = 'called number' 



NOTE: Only the call id assignment notification by the FP is represented here. The call id is however present in the 
last {CC-INFO} message from PP to FP. 

Figure 44: Example of call identifier assignment on outgoing call, with call-id = 3 

A call with basic service call class LiA service call setup' shall NOT be assigned any call identifier. See clause 7.4.10.6 
for more details. 
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7.4.6.3 Call identifier assignment on first incoming call (FP to PP) 

The purpose of this procedure is to have the FP, upon a first incoming call, external or internal, assign a call identifier 
and send it to the PP. 

NOTE 1: As described in clause 7.4.6.1, for an external incoming call, the FP may (but is not required to) assign 
different call identifiers to the different PPs for an external incoming call. 

NOTE 2: The "Handset locator" feature uses a kind of incoming call to which the FP also assigns a call identifier. 

In the case of an internal call, the FP shall assign a single call identifier for both PPs. 

In the case of an internal general call, the FP shall assign a single call identifier for all PPs. 

A Call identifier for an incoming call shall be sent from FP to PP in a «CALL INFORMATION» information 
element in the {CC-SETUP}message. 

NOTE 3: The call identifier should not be displayed to the user. 

The procedure shall be performed as procedure "Incoming call request" from GAP (see clause 8.12 of 
EN 300 444 [12]), with the following modification: the information element «Call information» with the content 
described in table 28 (see clause 7.4.6.1) shall be added to the content of the {CC-SETUP} message described in 
table 22 of clause 8.12 of EN 300 444 [12]. 



PP FP 





CC-SETUP 

< 




« CALL-INFORMATION, 


If the call is 
external 


< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information^ 

< Identifier value = 'xy'B > 






< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = '02'H > 




» 



Figure 45: Example of Call identifier assignment on incoming call, with call-id = 2 

7.4.6.4 Call status indication to the handset (FP to PP) 
7.4.6.4.1 Call status indication general requirements 

The procedure "Call status indication to the handset (FP to PP)" provides the PP with timely and accurate information 
about the PP current call status (or calls statuses). Call statuses are used for outgoing and incoming calls, external and 
internal calls, first and parallel calls. 

The call status and call status reason information is primarily intended for displaying to the user accurate MMI 
information. (For instance a parallel call dedicated menu will only show up when the call is really connected with 
remote peer). 

More specifically, the aim of the present procedure is to: 

• enhance parallel call user experience for all Part 3 devices, by allowing the building of a state machine on PP 
side for every call (first and especially parallel calls); 

• increase accuracy of state information exchange for Part 3 FPs that will rely on an 'Early {CC-CONNECT}' 
implementation, while not breaking other implementations (see 'Early {CC-CONNECT}' implementations 
below for more information). 
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The FP shall send the call status indication to the PP (see clause 7.4.6.4.3 for details). 

The PP may use this indication to inform the user of the status of the call (current procedure does not specify the way 
this information is displayed to the user. It could be a text string, an icon, etc.). 

For example, the PP may display to the user: 

• the communication duration; 

• context dependent menus; 

• feedback to a user action (e.g. second call initiation, call toggle, call transfer request, conference call request, 
etc.); 

• information about another user action (the current call becomes a conference call, is being intruded, 
transferred, etc.). 

Information conveyed by call statuses: Information provided to the PP (and user) includes: 

• real network-side normal call status ("call proceeding", "ringing", "connected", etc.). In other words, the PP is 
provided with the status of the call towards the peer party (between FP and peer party); 

• network-side call status in the case of busy/error conditions; 

• call status reason: In addition to the indicated call status, the FP shall send the call status reason, if available 
in an error message from network or from the FP itself. 

Link with original CC state machine (handling of radio link and first call). The present procedure does not make any 
change to the original CC state machine, nor to CC state transitions (as triggered by CC messages). Especially, this state 
machine still contains CC message ordering in both directions. U plane opening is still based on the «PROGRESS 
INDICATOR» IE or on the {CC-CONNECT} message. 

Rather, the present procedure adds a newly defined state machine (on PP side only) for each call including the first one, 
state transitions being triggered by the reception of call statuses (even for the first call). For 'Non-early 
{CC-CONNECT}' implementations, the sending of a call status for the first call generally coincides with the sending of 
the CC message of the same name. 

NOTE: Call status names are all prefixed with 'CS' for 'Call Status', in order to avoid any confusion with existing 
state transitions. For convenience, call statuses have names similar to the corresponding CC messages. 

Call status and external/internal calls: For external calls, call statuses originate from the FP or from the network. For 
internal calls, the call status always originates from the FP and is used with the same meaning. (For an internal call, 
both implementations send the {CC-CONNECT} message at the same time). 

'Early {CC-CONNECT}' implementations: (see definition in clause 7.4.6.1). In such implementations, the CALL 
ACTIVE state, defined as reached when the {CC-CONNECT} message is sent, does no longer mean end to end active 
call. On the contrary, the 'CS call connect' call status shall always mean end to end active call (see however the PSTN 
special case in clause 7.4.6.4.3). 

Call statuses shall also be used for first calls, even in "Non early {CC-CONNECT} implementations", because the PP 
cannot guess which type of implementation the FP uses. For example, the PP shall always rely on 'CS call connect' for 
being informed of end to end activation of the call, and never on {CC-CONNECT} reception per se (which only means 
U-plane connection). 

EXAMPLES: Clauses 7.4.6.4.5 to 7.4.6.4.9 provide several examples explaining the use of the call status 
indication procedure. It has to be noted that the sequences are only examples, it cannot be 
mandatory that the message flows shall always be exactly in the described way. However it is 
recommended to follow the examples where possible in order to ensure interoperability. 

Backward compatibility 

A Part 3 FP shall not send any call status to GAP or NG Part 1 devices. 

A Part 3 PP in front of a GAP FP or NG DECT Part 1 FP should behave as a GAP PP or NG DECT Part 1 PP 
respectively. 
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7.4.6.4.2 Call status indication as call information 

The call status indication shall be sent in the «CALL INFORMATION» IE. 



Table 29: Values used within CC-messages 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Call-information» 


identifier type> 


2 


Code for 'Call status' identifier type 


identifier subtype> 


1 


Code for 'Call status' subtype 


identifier value> 


All 


The 'Call status' value itself 


identifier type> 


2 


Code for 'Call status' identifier type 


identifier subtype> 


2 


Code for 'Call status reason' subtype 


identifier value> 


All 


The 'Call status reason' value itself 



Call identifier and call status 

Each time a call status is sent from FP to PP, the call identifier for the relating call shall be sent in the same «CALL 
INFORMATION» information element. 

7.4.6.4.3 Call status principles and values 

General rules. The following three call statuses shall always be sent: 

• 'CS call setup' (for all incoming calls); 

• 'CS idle' (for all calls, incoming or outgoing, first or parallel). However, the use of the 'CS idle' call status for 
the last released call is optional (see clause 7.4.3.5.4); and 

• 'CS call connect' (for all incoming and outgoing calls, first or parallel, but only when the call is end to end 
connected from PP to remote system, and unless 'CS conference connect' is used). 

NOTE 1: Contrary to the 'CS call connect', the {CC-CONNECT} message indicates local U-plane connection and 
is sometimes sent before the call is end to end connected. 

The rules for using call statuses are further detailed in the 'Values summary and condition of use' clause below and 
especially in table 30. 

Other call statuses shall also be sent by the FP if applicable or upon reception of the corresponding information from the 
network. 

A {CC-INFO} message shall not be used to convey a call status for the first call before the {CC-CONNECT} has been 
sent. In this case, the standard CC message shall be used instead. 

Contrary to the case of first calls, the procedure "Call status indication to the handset" introduces the concept of a state 
machine on PP side for the handling of parallel calls. Consequently, call statuses for a parallel call are not conveyed 
within specific CC messages and shall always be sent using the all-purpose {CC-INFO} message type. 

Call statuses for a first outgoing call: Call statuses shall be used for a first outgoing call. The sending of a call status 
by the FP shall be as timely and accurate as possible with regard to the external world situation (network, other 
handsets). 

For a 'Non early {CC-CONNECT}' implementation of the FP, the sending of a call status for a first outgoing call shall 
coincide with the sending of the corresponding CC message: 

• the call statuses CS call setup ack, 'CS call proc', and 'CS call alerting' are optional and shall be sent in 
{CC-SETUP-ACK}, {CC-CALL PROC}, {CC- ALERTING} respectively. The call status is used if and only if 
the corresponding message is used; 

• the call status 'CS call connect' shall always be used (if the call succeeds), and shall always be sent in the 
{CC-CONNECT} message. 
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For an 'Early {CC-CONNECT}' implementation the sending of a call status for a first outgoing call shall be done by 
means of a {CC-INFO} message for call statuses sent after the {CC-CONNECT}. More specifically: 

• the {CC-CONNECT} message shall not bear any call status; 

• the call statuses 'CS call setup ack', 'CS call proc', and 'CS call alerting' are optional and - for those which are 
used - shall be sent in this order in separate {CC-INFO}messages following the {CC-CONNECT} message; 

• the call status 'CS call connect' shall always be used (if the call succeeds) and shall be sent after the previously 
mentioned call statuses in a {CC-INFO} message following the {CC-CONNECT} message. 

Call statuses for a parallel outgoing call: Call statuses shall be used for a parallel outgoing call. More specifically: 

• the call statuses 'CS call setup ack', 'CS call proc', and 'CS call alerting' are optional and - for those which are 
used - shall be sent in this order in separate {CC-INFO}messages, as part of the outgoing parallel call 
initiation (see clause 7.4.3.5.1); 

• the call status 'CS call connect' shall always be used (if the call succeeds) and shall be sent after the previously 
mentioned call statuses in a {CC-INFO} message. 

Call statuses for a first incoming call: Call statuses shall be used for a first incoming call. More specifically: 

• the call status 'CS call setup' shall always be used, and shall be sent within the incoming {CC-SETUP} 

message; 

• the call status 'CS call connect' shall always be used, and shall be sent within a {CC-INFO} following the 
{CC-CONNECT-ACK} message. The {CC-CONNECT- ACK} message shall never be used to convey any 
call status. 

Call statuses for a parallel incoming call: Call statuses shall be used for a parallel incoming call. More specifically: 

• the call status 'CS call setup' shall always be used, and shall be sent in a {CC-INFO} message, as part of the 
call waiting indication (see clause 7.4.3.5.2); 

• the call status 'CS call connect' shall always be used, and shall be sent in a {CC-INFO} message if (and after) 
the call is accepted (see clause 7.4.3.5.6). 

NOTE 2: The sending of the 'CS call connect' call status by the FP for a first incoming call corresponds to the 

sending of the {CC-CONNECT-ACK} message, but is however sent in a separate {CC-INFO} message. 

Call statuses for held and released calls: Call statuses shall be used for putting a call on-hold or for releasing a call: 

• the call status 'CS call hold' shall be used, and shall be sent in a {CC-INFO} message, in order to put a call 
on-hold (see clauses 7.4.3.5.1 and 7.4.3.5.8); 

• the call status 'CS idle' shall be used, and shall be sent in a {CC-INFO} message, if the call is to be released on 
PP side (see clause 7.4.3.5.4). However, use of this call status is optional for the last call; 

As soon as a call is held (CS call hold) or released (CS idle) and until another call is connected (CS call connect), the FP 
shall play appropriate audio toward the PP. Appropriate audio consists in: 

• audio received from the network if any (e.g. announcements); 

• audio translation of network events if any (e.g. waiting call message from network); 

• mute patterns otherwise (FP sends mute pattern as defined in TS 102 527-1 [21]). 

NOTE 3: If an additional local muting is performed on PP side during those "transition" periods, this should be 
carefully handled as this would also mute possible audio received from the network or FP (e.g. inband 
call waiting tones, network announcements). 

Call remote status notification: 'CS call remote connect' and 'CS call remote hold' call statuses are used to notify the 
PP of the connected or on-hold status of the call on remote handset side. See table 30 below and clause 7.4.3.5.12 (call 
remote status notification) for more details. 
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Special case of PSTN calls: The use of call statuses for external calls on a PSTN line is described in procedure 
'Handling of lines where second calls are signalled in-band' of clause 7.4.3.10. 

Values summary and condition of use: Table 30 explains use of the call status values defined in EN 300 175-5 [5], 
clause 7.7.56, "Call information". 



Table 30: Call status value explanation 



Call status 


Use 


Status 


Explanation 


CS call setup 


Incoming 
call 


Mandatory for incoming calls 


Incoming call presentation to local handset 
The handset has not yet confirmed user alerting 
(e.g. CS call alerting not yet sent) 


CS call setup ack 


Outgoing 
call 


If and only if the FP (or the 
network) is expecting to collect 
further dial information 




CS call proc 


Outgoing 
call 


If and only if the network 
provides corresponding 
signalling 


Call is proceeding. Dial information is assumed to be 
complete. The FP has started outgoing call towards 
the network (or internal party). No final response from 
network or internal party has been received yet 


CS call alerting 


Outgoing 
call 


If and only if the network 
provides corresponding 
signalling or for internal call 


Outgoing call is signalled (ring back) at called party 
side. A waiting call uses a control code for the same 
purpose in the opposite direction 


CS call connect 


Both 


Mandatory for all successful 
calls (unless CS conference 
connect is used) 


End to end call is connected from PP to remote 
system, and locally active; voice is available if the 
remote handset is also connected (i.e. not on hold) 


CS call 
disconnecting 


Both 




Disconnect in progress, used from FP to differ the 
sending of 'CS idle' in order to signal in-band and/or 
Call status reason information to the handset 


CS call hold 


Both 


If and only if applicable 


connection is being held locally 


CS call under 
transfer 


Both 


If and only if applicable 


Used for unannounced call transfer in 

clause 7.4.3.6.2, to indicate that the incoming call is 

used for a call transfer 


CS conference 
connect 




If and only if applicable 


3PTY conference is active 

If used, replaces CS call connect 


CS call 
intercepted 




If and only if applicable 


Used in the "Headset management" feature (see 
clause 7.4.16.2.2, Call interception) 


CS idle 


Both 


Mandatory for all calls except 
the last call; Optional for the 
last call 


Indicates that the corresponding call context shall be 
deleted on PP side at least. For more detail, see 
clauses 7.4.3.5.4 and 7.4.6.1 


CS call remote 
connect 


Call remote 

status 

notification 


Optional for the PP and the FP 


Status of the call on the remote end of that call is 
'connected' or 'on-hold' respectively; see clause 
7.4.3.5.12 (call remote status notification). These 
remote statuses allow to improve the local PP MMI, 
but do not interfere in any way with the local statuses 
defined above 


CS call remote 
hold 


Call remote 

status 

notification 


Optional for the PP and the FP 



7.4.6.4.4 Call status reasons summary and MMI mapping 

The following table explains the use of the call status reason values defined in EN 300 175-5 [5], clause 7.7.56 'Call 
information'. 



Table 31 : Call status reason value explanation 



Call status reason 


Explanation 


system busy 


Call cannot be proceeded due to general resource problems of the FP 


line in use 


Call cannot be proceeded, because the chosen line (see clause 7.4.5.2 Line 
identification for external outgoing calls) is in use 


control code not supported 


Shall be sent by the FP if the control code sent by the HS is not supported 


control code failed 


Shall be sent by the FP if execution of the control code sent by the HS was not 
possible or failed (for internal reasons or due to negative network response) 


user busy 


Called party is busy 


number not available 


Called number not available 
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Table 32 gives some examples of which user interactions are possible when existing calls are in the indicated call 
statuses ('CS idle' being used also for not yet existing calls), especially for double call scenarios. 



Table 32: Mapping of call status (reason) to PP user interface actions 



Call statuses 


Reasonable display or control codes offered by the user 
interface of the PP in relation to the indicated call statuses 


Call id 1 


Call id 2 


CS call connect 


CS idle 


Initiating a second call external or internal / Call release / Putting a 
call on-hold 


CS call hold 


CS call setup ack / CS call 
proc / CS call alerting 


Call release / Call transfer request 


CS call hold 


CS call connect 


Call toggle request / 3-party conference call request / Call release / 
Call transfer request 


CS call connect 


CS call setup 


Call waiting acceptance / Call waiting rejection 


CS call hold 


CS idle 


Resuming a call put on-hold 


CS call disconnecting 
+ reason 'user busy' 


CS idle 


PP should present a "user busy" display 



NOTE: Table 32 does not list all possible call status combinations. 
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7.4.6.4.5 Call statuses for a first "Outgoing external call" 



PP 



FP 



CC-SETUP 



CC-SETUP-ACK 



Store call in call table 
and assign call id 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

CC-INFO 



« MULTI-KEYPAD. < KevDad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

» 

CC-CALL-PROC 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call proc' > 

» 

CC-ALERTING 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = CS call alerting' > 

» 

CC-CONNECT 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call connect' > 



start outgoing call 
towards peer party 



network message 'peer 
party is alerting' 



network message 
'peer party is active' 



Figure 46: Example of call status indication on outgoing call 

NOTE: For conciseness of the diagram, figure 46 does not show the exchange of line identifiers. 
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7.4.6.4.6 Call statuses for a first "Outgoing external call" 

using early {CC-CONNECT} message 



PP 



FP 



CC-SETUP 



CC-CONNECT 



Store call in call table 
and assign call id 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 



Early CC-CONNECT 
message used: 
CS call connect call status 
not yet reached 



CC-INFO 

« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03 H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 



CC-INFO 



« MULTI-KEYPAD. < KevDad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 



< Identifier value = '03'H : 



» 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call proc' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call alerting' > 

» 

CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = CS call connect' > 



start outgoing call 
towards peer party 



network message 
'peer party is alerting' 



network message 
'peer party is active' 



Figure 47: Example of call status indication on first outgoing call using early {CC-CONNECT} 

NOTE: For conciseness of the diagram, figure 47 does not show the exchange of line identifiers. 
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7.4.6.4.7 



Call statuses for an "Outgoing external call" - user busy 
PP FP 



Call established with 
call id = '03'H, and call status = 'CS call proc' 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = CS call disconnecting' > 

< Identifier type = 'Call status' > 

< Identifier subtype = 'Call status reason' > 

< Identifier value = 'user busy' > 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS idle' > 

» 

CC-RELEASE 



CC-RELEASE-COM 



network message 
'user busy' 



timeout 



Figure 48: Example of call status indication on outgoing call, user busy 

NOTE: For conciseness of the diagram, figure 48 does not show the exchange of line identifiers. 
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7.4.6.4.8 



Call statuses for an "Outgoing external call" - number not available 
PP FP 



Call established with 
call id = '03'H, and call status = 'CS call proc' 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = CS call disconnecting' > 

< Identifier type = 'Call status' > 

< Identifier subtype = 'Call status reason' > 

< Identifier value = 'number not available' > 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS idle' > 
» 



CC-RELEASE 



CC-RELEASE-COM 



network message 
'number not available' 



timeout 



Figure 49: Example of call status indication on outgoing call, number not available 

NOTE: For conciseness of the diagram, figure 49 does not show the exchange of line identifiers. 
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7.4.6.4.9 Call statuses for a first "Incoming external call" 



PP FP 







Incoming external 


CC-SETUP 


4 


call 


•4 

« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value ='CS call setup' > 




» 




CC-ALERTING 




► 

CC-CONNECT 




► 

CC-CONNECT-ACK 
< 




CC-INFO 




4 

« CALL-INFORMATION, 

< Identifier type/subtype = Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call connect' > 




» 





Figure 50: Call statuses for a first "Incoming external call" 
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7.4.7 Multiple lines handling 

7.4.7.1 Multiple lines common requirements 

The "Multiple lines" feature describes the behaviour of DECT systems connected to more than one network lines. A PP 
registered in such a DECT system may be attached to one or several of these lines. 

The "Multiple line" feature is only useful if the DECT system is connected to at least two different lines. 




Figure 51 : Example of a multiple line configuration with 3 lines (with attachments) 
PPs attached to several lines are hatched 



When implementing the "Multiple lines" feature, the PP shall set the corresponding terminal capability bit. The FP shall 
set bit a 34 of the "Extended higher layer capabilities (part 2)" (see EN 300 175-5 [5], clause F.3). 



7.4.7.1.1 Pre-requisites 

The following pre-requisites for implementation of the "Multiple lines" feature shall be taken into account: 

• A FP implementing the "Multiple lines" feature shall implement the "Line identification" feature as a 
pre-requisite. 

• A PP implementing the "Multiple lines" feature shall implement the "Line identification" feature as well. 

• A PP or FP implementing the "Multiple lines" feature shall implement the feature entitled "Common parallel 
call procedures" of clause 7.4.3.5 as a pre-requisite, so that a new call on a different line can be placed or 
received on an already in use handset. 



7.4.7.1.2 Minimum requirements 

An implementation of the "Multiple lines" feature on a DECT system shall comply with the following minimum 
requirements: 

• The "Maximum number of simultaneous calls" supported by a FP implementing the "Multiple lines" feature 
shall be at least equal to 2. This includes support of as many simultaneous call contexts. 

• As the support the "Common parallel call procedures" of clause 7.4.3.5 (see clause 7.4.8.1.1) is a prerequisite, 
a PP implementing the "Multiple calls" feature shall support at least two simultaneous call contexts. 

NOTE: The last provision allows a multiple line PP attached to several lines to handle parallel call situations and 
can be seen as a consequence of the required support of the "Common parallel call procedures" of 
clause 7.4.3.5 (see clauses 7.4.7.1.1 and 7.4.7.2). 
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7.4.7.2 Terminal attachment and line settings 

All registered PPs shall be attached to at least one line. A multiple line PP shall be prepared to be attached to at least 
two lines. 

EXAMPLE 1 : A PP could be attached to a PSTN line and a VoIP line at the same time. 

More specifically, a multiple line PP shall provide a way for the user to select one of the available lines. 

EXAMPLE 2: Line selection could be offered to the user through a menu, or by entering the keypad information 
#k, where k is the selected line number. 

The PP should consult the Line Settings List in order to offer only available line choices to the user (i.e. the list of lines 
the PP is attached to). 

7.4.7.2.1 Initial attachment 

The FP shall provide at least one of the following two possible attachment modes: 

• FP-managed attachment: After subscription registration the PP is attached by the FP to one or several lines 
with no specific user intervention. 

For an FP-managed attachment, and in order to know the set of lines it is attached to, the PP may read the 
"Attached handsets" setting of all Line Settings List entries via the "List access service" feature [NG1.N.16]. 

• PP-managed attachment: Default attachment is updated by the PP during or just after subscription 
registration. 

An initial PP-managed attachment shall be implemented as an update of the "Attached handsets" setting for 
every entry in the Line Settings List corresponding to a targeted line, and performed via the "List access 
service" feature [NG1.N.16]. 

7.4.7.2.2 Attachment modification 

The PP should be able to change the initial attachment (add or remove lines) during or after location registration. If 
supported, the PP shall initiate the procedure. 

An attachment modification shall be implemented as an update of the "Attached handsets" setting for every entry in the 
Line Settings List corresponding to a targeted line, and performed via the "List access service" feature [NG1.N.16]. 

7.4.7.2.3 Line settings 

The FP shall support the "List access service" feature [NG1.N.16] and the Line Settings List. 

Apart from the "Attached handsets" setting itself, a PP shall only be able to update the settings of the lines it is attached 
to. 

7.4.7.3 Incoming and outgoing external calls on a multiple line system 

This procedure applies to the FP and to a PP attached to one or more line(s), and to one of these lines where a new call 
(incoming or outgoing) occurs (line A in table 33). If the PP is idle, or already in communication on that line, no 
specific requirement is needed. Conversely, if the PP is already in communication on another line (line B in table 33), 
specific requirements are needed. Table 33 details the procedures to be used. 
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Table 33: Incoming and outgoing external calls on a multiple line system 





Incoming call on line A 


Outgoing call on line A 


All idle PPs 


Usual "mono-line" requirements apply 
(see notes 1 and 2) 


Usual "mono-line" requirements apply 
(see notes 1 and 2) 


All PPs attached to line A 
and in communication on line A 


All PPs attached to line A and B 
in communication on line B but not A 
(parallel incoming or outgoing call on 
another line A; see note 3) 


"Call waiting indication (external or 
internal)" (see clause 7.4.3.5.2), shall 
be used (see note 1 ) 


"Outgoing parallel call initiation" 
(see clause 7.4.3.5.1) shall be used 
(see note 1 ) 


NOTE 1 : In any case, "Line identification" shall be used on PP and FP side. 

NOTE 2: The new call on line A may be a first call or a parallel call. If the line A is a multiple call line, please refer to 

clause 7.4.8.2, "Incoming and outgoing external calls on a multiple call line"; otherwise, usual procedures 

defined in the present DECT standard apply. 
NOTE 3: In this case, the PP is necessarily attached to several lines (at least A and B). The PP is busy with line B but not 

A, which means that with regards to line A it is not involved in any call. However, as it is not idle, parallel call 

procedures apply (feature "Common parallel call procedures" of clause 7.4.3.5). 



7.4.7.4 Internal calls in multiple line context 

This procedure applies to the FP and a PP attached to one or more line(s). 

Internal calls in multiple line context shall be possible between any two PPs, even if there is no line to which both PPs 
are attached. 

It should be possible to forbid internal calls between PPs that do not share a common line by configuration of the DECT 
system. 

7.4.7.5 Compatibility with non multiple line PP or FP 

This procedure applies to a non multiple line DECT equipment (PP or FP) in front of a NG-DECT Part 3 PP or FP 
implementing the "Multiple lines" feature. 

Non multiple line DECT equipment include: 

• NG DECT Part 3 FP, not implementing the "Multiple lines" feature; 

• NG DECT Part 1 PP or FP; 

• GAP PP or FP. 

NOTE: GAP and NG-DECT Part 1 PPs not implementing the "Multiple lines" feature do not necessarily mean 
that the PP is attached to only one line. It only means that the PP is not aware of possible multiple 
attachments. 

7.4.7.5.1 Non multiple line PP in front of a multiple line FP 

Attachment: A non multiple line PP shall use FP-managed attachment and is not aware of the lines it is attached to 
(only the user is). 

Outgoing calls: 

• A non multiple line NG-DECT Part 3 PP may use FP-managed line selection (see clause 7.4.5.2.4), and should 
however use the line identifier notification received to notify the user of the line used. 

• A non multiple line GAP, NG-DECT Part 1, or NG-DECT Part 3 PP may use the '#' key based line selection 
mechanism of clause 7.4.5.2.3 ("Backward compatible line identification for a first external outgoing call 
using «MULTI-KEYPAD» IE"). In that case, the user manually enters the line identifier after the '#' key. 

Incoming calls: A non multiple line PP shall receive all incoming calls arriving on one of the lines it is attached to; a 
Part 3 PP should however use the line identifier received to notify the user of the line used. 



ETSI 



144 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



7.4.7.5.2 Non multiple line FP in front of a multiple line PP 

In front of a "non multiple line" FP (hence connected to at most one line), a PP implementing the "Multiple lines" 
feature is however attached to a single line: 

• In front of a Part 3 FP, it shall however send the corresponding line id for each call, as specified in 
clause 7.4.5.2.2 (or alternatively clause 7.4.5.2.3), or use "FP-managed line selection", as specified in 
clause 7.4.5.2.4.1 (sending 'None' value instead). 

• In front of a GAP or Part 1 FP, it shall not send any line identifier. 

7.4.8 Multiple call line handling 
7.4.8.1 Multiple calls general requirements 

The "Multiple calls" feature represents the ability for a FP and PP to support several fully parallel calls (outgoing or 
incoming) to and from a single line supporting the "Multiple call" mode. 




Figure 52: A multiple-call line with three simultaneous calls 



This feature is especially useful when several calls are placed or received on different handsets at the same time. 
However, a multiple call enabled DECT system is compatible and can be connected to a non multiple call line like a 
PSTN line. 

From the DECT system point of view, a multiple call line may be configured in "single call" mode. To configure a 
multiple call line in "single call" mode, or the other way round, the "Multiple call mode" setting of the "DECT System 
Settings List" (see clause 7.4.11.4.8) shall be used through the "List access service" feature [NG1.N.16]. 

NOTE 1: PSTN double calls are also a kind of multiple calls on a single line, but always with a single handset for 
both calls, and only one call context active at a time. 

NOTE 2: "Multiple calls" is most notably a feature brought by VoIP protocols, allowing several call contexts to be 
opened simultaneously on network side. 



7.4.8.1.1 Pre-requisites 

The following pre-requisites for implementation of the "Multiple calls" feature shall be taken into account: 

• A PP or FP implementing the "Multiple calls" feature shall implement the "Call identification" feature as a 
pre-requisite. 
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• A PP or FP implementing the "Multiple calls" feature shall implement the feature entitled "Common parallel 
call procedures" of clause 7.4.3.5 as a pre-requisite, so that a new call can be placed or received on an already 
in communication PP. 

NOTE: On FP side, implementation of the feature entitled "Common parallel call procedures" also implies 
implementation of the "Line identification" feature. 

7.4.8.1.2 Minimum requirements 

An implementation of the "Multiple calls" feature on a DECT system shall comply with the following minimum 
requirements: 

• The "maximum number of simultaneous calls" supported by a FP implementing the "Multiple calls" feature 
shall be at least equal to 2. This includes support of as many simultaneous call contexts. 

• The FP shall be able to support this maximum number of incoming or outgoing calls for idle PPs as defined in 
clause 7.4.6.2. This includes simultaneous ringing of all idle PPs on incoming calls and availability of all idle 
handsets for placing a new call when there is already a call going on on the line. 

• As the support the "Common parallel call procedures" of clause 7.4.3.5 (see clause 7.4.8.1.1) is a prerequisite, 
a PP implementing the "Multiple calls" feature shall support at least two simultaneous call contexts. 

7.4.8.2 Incoming and outgoing external calls on a multiple call line 

This procedure applies to the FP and the PP at external call (incoming or outgoing) setup on a multiple call line. This 
line might be set in "multiple call" or "single call" mode. 

7.4.8.2.1 Line set in "single call" mode 

On a multiple call line configured in "single call" mode, only one call can be active at a time on the line. Other calls 
(second, or further) are on4iold and can only become active by replacing the existing one on the same PP. 

To handle a line in "single call" mode, the DECT system shall use the usual procedures defined in the present 
document. In particular, the feature entitled "Common parallel call procedures" shall be used to handle the second or 
further call on the same PP. 

If the line is busy, but implicit call intrusion is enabled by configuration, clause 7.4.3.8.1 shall be used instead of the 
"Busy system or line notification" procedure (see clause 7.4.8.3). 
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7.4.8.2.2 Line set in "multiple call" mode 

On a multiple call line configured in "multiple call" mode, several calls may be active simultaneously; second and 
further calls are presented to all PPs (idle or busy) attached to the line. Table 34 details the procedures to be used. 



Table 34: Line set in "multiple call" mode 





Incoming call setup 


Outgoing call setup 


On all idle PPs 
attached to the line 


GAP 8.12 "Incoming call request" shall be used 
(see note 1 ) 


GAP 8.2 "Outgoing call request" shall be used 
(see note 2) 


On all busy PPs 
attached to the line 


"Call waiting indication" (see clause 7.4.3.5.2), 
shall be used (see notes 3, 4 and 5) 


"Outgoing parallel call initiation" (see 
clause 7.4.3.5.1) shall be used (see notes 2 
and 3) 


NOTE 1 : Unless the DECT system is busy (see clause 7.4.8.3), although the line was not, in which case the call is 
not presented. 

NOTE 2: If the DECT system is busy, the "Busy system or line notification" procedure (see clause 7.4.8.3) shall be 
used back. 

NOTE 3: All "Common parallel calls procedures", then, apply for handling the parallel calls. The fully parallel calls 

are in this case only alternatively active as for PSTN double calls. 
NOTE 4: On a multiple call line with VoIP interface, a call waiting procedure for already in use handsets may be 

used in the following two cases: a second VoIP call is received, or an in-band call waiting tone from a 

PSTN to VoIP gateway is received. However, the used procedures are the same. 
NOTE 5: If the call is meanwhile accepted by another PP, or if the remote party hangs up before the call is accepted 

by any PP, the call shall be then released by the FP towards the current PP (see clause 7.4.3.5.4). 



7.4.8.3 Busy system or line notification 

This procedure applies to the FP and a PP that initiated an outgoing call (external or internal) at a point in time where 
the FP and/or the line cannot support the additional call. The new outgoing call may be a first call, or a parallel call. 

NOTE 1 : The current procedure applies within an outgoing call setup attempt. For idle PPs, a «DISPLAY» 

notification can also be used outside of any call for preventing call setup attempts, especially on a line in 
single -call mode. 

NOTE 2: In single call mode, the line is considered busy for idle PPs, as soon as one call is going on on it. 

Busy line: A busy line is a line for which no new incoming or outgoing call can be performed, because all of the 
available bandwidth is used. This concept is especially relevant for multiple call lines. 

Busy system: A DECT system is busy if the FP is not able to support any additional call, because the maximum 
number of call contexts it can handle has been reached. The system may be busy without the line being busy. 

NOTE 3: A call context could be used by an internal call. A system should allow as many calls (external or 
internal) as there are call contexts potentially available on the system. 

On call setup attempt (first or parallel), if the system is busy or the line is busy, the FP shall send back a "busy system 
or line notification" back to the PP, in the form of a {CC-INFO} message with «CALL_INFORMATION> IE 
containing: 

• the call status 'CS call disconnecting' and the appropriate call status reason, (e.g. 'line in use' or 'system busy'). 

• the call identifier assigned for the call. This may be the first time it is communicated to the PP. 

NOTE 4: On the contrary, 'CS idle' cannot be sent with a newly assigned call id. 

Before the present procedure is used, at least one CC message different from {CC-INFO} shall have been sent from FP 
to PP. 

Whenever required by the "Tones provision" feature, the FP shall additionally send a «SIGNAL» information 
element with <Signal value> field equal to 04H ('busy tone') included in a CC-INFO message. 
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If the PP does not hook on after a time-out has elapsed, the FP shall send a call release request to the PP to terminate the 
call attempt. This call release request shall take the form of a CC-RELEASE message for a first call, or of a 
{CC-INFO} message according to procedure "Call release and call release rejection" (see clause 7.4.3.5.4), for a 
parallel call. 



PP 

attached to 
a multiple-call line 



FP 
I 

the FP and/or the multiple call 
line cannot support the 
additional call: 



CC-INFO 



If required by the Tones provision' feature « SIGNAL, < value = 'busy tone' = 04'H > » 



« CALL-INFORMATION, 

< id type/subtype = Call identifier' value = '03'H > 

< id type/subtype = 'Call status' value = CS call disconnecting' > 

< id type = 'Call status' id subtype = Call status reason' value = 'line in use' > 

» 



CC-INFO 



After some 
time out 



« SIGNAL, <value = Tones off = '3F'H > » 

« CALL-INFORMATION, 

< id type/subtype = Call identifier', value = '03'H > 

< id type/subtype = Call status', value = CS idle' > 

CC-RELEASE 



CC-RELEASE-COM 



Figure 53: Busy system or line notification for call with defined call-id=3 



7.4.9 PP and FP capabilities indication and broadcast 
7.4.9.1 Terminal capability indication 

NOTE 1: This procedure description replaces clause 8.17 of EN 300 444 (GAP) [12]. 

The PP shall be able to send the «Terminal capability» information element and the FP shall be able to receive it at 
least in {ACCESS-RIGHTS-REQUEST} and when location registration is supported in the { LOC ATE-REQUEST } . 
The following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 



Table 35: Values used within the «TERMINAL CAPABILITY» information element 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Terminal 
capability» 


<Display capability> 


All 


If PT supports feature (GAP.N.24) it 
shall indicate in this field value which 
is equal to or higher than 2 


<Tone capability> 


All 




Echo parameters 


3 


VoIP compatible TCLw. See note 1 


Ambient noise Rejection 
(N-REJ) 


[1.2] 


See note 2 


Adaptive volume control 
(A-VOL) 


[1,2, 3] 


See note 2 


Slot type capability 


All 


Full and long 640 slots mandatory; 
double and long 672 optional. See 
also note 2 
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Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 




<Profile indicator 1>, 
bit 2 


"xxxxx1x"B 


GAP and/or PAP supported 




<Profile indicator 6>, 
bit 6 


"xXxxxxx"B 
X = [0,1] 


Fast or slow hopping radio 




<Profile indicator 6>, 
bit 7 


"Xxxxxxx"B 
X = [0,1] 


Support (or not support) of 
"no-emision" mode (optional MAC 
service [NG1.M.5]) 




<Profile indicator_7>, 
bits 2 and 3 


"xxxx11x"B 


New Generation DECT part 1 
(wideband speech) and part 3, 
(extended wideband speech services) 
supported 




<Profile indicator 7>, 
bit 4 


"xxxXxxx"B 
X = [0, 1] 


Support (or not support) of the 
"Headset management" feature 
[NG1.N.21] 




<Profile indicator_7>, 
bit 5 


"xxXxxxx"B 
X = [0, 1] 


Support (or not support) of the 
'Re-keying' and 'default cipher key 
mechanism early encryption' (related 
to feature [GAP. N. 35]) 




<Profile indicator_7>, 
bit 6 


"xXxxxxx"B 
X = [0, 1] 


Support (or not support) of the 
'associated melody' per contact 
(related to procedure 'PT Alerting 
using pattern signalling' 7.4.1.9) 




DSAA2 (Octet 5) 


[0,1] 


Support (or not support) of the DSAA2 
(see EN 300 175-7 [7]). 




DSC2 (Octet 5) 


[0,1] 


Support (or not support) of the DSC2 
(see EN 300 175-7 [7]). 




<Control codes> 


All 


If PT supports feature (GAP.N.25) it 
shall indicate in this field value which 
is equal to or higher than 2 


NOTE 1 : PPs compliant with the present document shall always set the value 3 ('1 1 'B) as result of the audio type 
requirements (see clause 6.8 table 7). FPs shall also understand the values 1 ('01 'B) and 2 ('10'B) that 
may be set by PPs compliant with NG-DECT Part 1 [21] or GAP [12] when attached to FPs compliant to 
the present document. 

NOTE 2: This capability is assumed as the default value (see table 36) if the «TERMINAL-CAPABILITY» 
information element is omitted. 



The capabilities in table 36 shall be assumed as default if the following fields in the «TERMINAL CAPABILITY» 
information element are not present. 

Table 36: Values assumed as terminal capabilities 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Terminal capability» 


<Echo parameters> 


3 


VoIP compatible TCLw (see 
note 1) 


<N-REJ> 


1 


No noise rejection 


<A-VOL> 


1 


No PP adaptive volume control 


<Slot type capability> 


"xxx1x1x"B 


Full slot and Long slot (j=640) 
supported (see note 2) 


<Profile indicator 6>, 
bit 7 


"0xxxxxx"B 


No support of "no-emision" mode 
(optional MAC service [NG1.M.5]) 


<Profile indicator 6>, 
bit 4 


"xxx0xxx"B 


No support of the "Headset 
management" feature [NG1.N.21] 


<Profile indicator 7>, 
bit 5 


"xx0xxxx"B 


No support of "Re-keying" and 
"default cipher key early encryption 
mechanism" 


DSAA2 (Octet 5) 





No support of the DSAA2 


DSC2 (Octet 5) 





No support of the DSC2 


NOTE 1 : Value 3 (VoIP compatible TCLw) shall be assumed if the PP has declared to be a NG-DECT Part 3 PP. For 
GAP and NG-DECT Part 1 PPs the default values given in [12] and [21] shall be assumed. 

NOTE 2: This value shall be assumed if the PP has declared to be a NG-DECT Part 3 or part 1 PP. For GAP PPs 
the default values given in [12] shall be assumed. 
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No echoing of characters is allowed in the FT and therefore the PT would be responsible for displaying dialled digits. 
All display information from the FT would be assumed to be additional information that the PT shall display in 
addition. The PT shall logically separate display information originating at the FT and PT. This could be achieved, for 
example, by one physical display and two logical displays or two physical displays and two logical displays. The key 
point is that display characters from the PT and FT shall not be simultaneously interleaved/mixed on the same physical 
display. 

7.4.9.2 Higher layer information FP broadcast 

The FP and PT shall support the broadcast of Higher Layer capabilities as part of Q T MAC broadcast messages (see 
clauses 7.6.3, 7.6.4 and 7.6.5). 

The broadcast attributes are a small set of NWK layer and DLC layer capabilities (jointly known as "higher layer 
capabilities") that shall be broadcast regularly as part of the MAC layer broadcast service. See EN 300 175-5 [5], 
annex F. 

RFPs belonging to the same LA shall broadcast the same values of higher layer attributes (see EN 300 175-5 [5], 
annex F) at any given time. 

The PP shall be capable to read and interpret at least the following broadcast attributes codings during locking 
procedure. In the locked state the PP may assume them as static. 

FP and PT shall support the following values of "Higher Layer capabilities" information attributes. 

7.4.9.2.1 Higher layer information in standard FP broadcast (Qh = 3) 

The requirements of clause 7.3.9.1 of TS 102 527-1 [21] shall apply. 

7.4.9.2.2 Higher layer information in Extended FP broadcast (Qh = 4) 

No Extended higher layer capabilities bits are used by the present document. 

7.4.9.2.3 Extended Higher Layer capabilities part 2 (Qh = 11) 

The Extended Higher Layer capabilities, part 2, Fixed Part Information field shall be used indicating the supported set 
of Wideband speech Services. 



ETSI 



1 50 ETSI TS 1 02 527-3 V1 .5.1 (201 3-03) 

Table 37: Extended Higher Layer Capabilities part 2 interpretation by the PP 



BIT Number 


Attribute 


Value 


Note 


< a 24> 


NG-DECT Wideband voice 
supported 


1 


See TS 102 527-1 [21] (see notes 1 and 2) 


< a 29> 


NG-DECT extended 
wideband voice services 
supported 


1 


The present document (see notes 1 and 2) 


< a 30> 


Permanent CLIR 


[0, 1] 


Related procedures: clause 7.4.12 


<a 31 > 


Third party conference call 
(external or external) 


[0,1] 


Related procedures: clause 7.4.3.7 


<a 32 > 


Intrusion call 


[0,1] 


Related procedures: clause 7.4.3.8 


<a 33 > 


Call deflection 


[0,1] 


Related procedures: clause 7.4.4.1.1, 7.4.4.2 


<a 34 > 


Multiple lines 


[0,1] 


Related procedures: clause 7.4.7 


<a 35> 


"no emission" mode support 


[0, 1] 


Related procedures: see NG1.M.5 in clause 6.12 


< a 42 > 


Support of 'Re-keying' and 
'early encryption' 


[0, 1] 


Support (or not support) of the 'Re-keying' and 
'default cipher key mechanism early encryption' 
procedures (related to feature [GAP. N. 35]) 


<a 43 > 


DSAA2 supported 


[0,1] 


Support (or not support) of the DSAA2 
See EN 300 175-7 [7]. 


< a 44 > 


DSC2 supported 


[0,1] 


Support (or not support) of the DSC2 
See EN 300 1 75-7 [7] and note 3. 


NOTE 1 : Value refers to the value to be set by FPs complying with the present document. PPs may need to 
understand other values due to the compatibility with GAP and NG-DECT Part 1 FPs. 

NOTE 2: All equipment compliant with the present documents shall broadcast and shall understand the "Extended 
Higher layer capabilities (part 2)". 

NOTE 3: The support of the DECT Standard Cipher #2 (DSC2) requires the support of the DECT Standard 
Authentication Algorithm #2 (DSAA2). 



Even if a capability bit relates to a feature which is mandatory in the present document, this bit shall be set (indicating 
the support of the feature). Setting only the bit a 29 NG-DECT "extended wideband voice services supported" is not 
sufficient. 



7.4.10 List access service 
7.4.10.1 General considerations 

Equipment supporting New Generation DECT Part 3 shall support the "List access service" feature as described in the 
present clause. The lists managed by this feature are structured as represented in figure 54. 



Contact 
List 



. name 
. first name 
. contact 
number 
. associated 
melody 



n entries 



Internal Names 
List 



. number 
. name 
. Call 

interception 



n entries 



User data oriented lists 



etc. 



-> -4- 



DECT System 
Settings List 



Line Settings List 



. FP registra- 
tion mode 
. PIN code 
. clock master 
. Base reset 
. FP IP 
address 
. FP version 



Line id 
Line name 
attached PP 
dialling prefix 
FP melody 
FP volume 
blocked nb 
multiple calls 



1 entry 



m entries (1 entry per line) 



DECT system and line settings lists 



list access 



Figure 54: Structure of the lists managed by the "List access service" feature 
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The list access feature defines a generic way to access lists located in the FP from the PP, through the use of commands. 
Commands allow to read, edit, and delete lists. 

NOTE 1 : List deletion only means emptying of the list. The list itself is still available after deletion. 

Note that the word command is used below with two different (although related) meanings, and, except when 
specifically stated, only the context allows to distinguish between them. A command is: 

either a basic message sent from PP to FP or from FP to PP (command as a message), 

or a complete exchange between the PP and the FP for reading, editing, or deleting a list (command as a 
complete exchange). 

Command as a message. The list access feature uses commands that are based on {IWU-INFO} messages, which 
contain the information element «IWU to IWU», using the dedicated protocol discriminator '03'H. The general 
structure of a command (as a message) is indicated in table 38. 



Table 38: Values used within the «IWU to IWU» information element 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 


<S/R bit> 


1 


Transmission of message 


<Protocol Discriminated 


03H 


List access 


<Command> 


1 ...127 


List access command (see note) 


<Command specific byte 0> 












<Command specific byte L-2> 






NOTE: Values from 128 on are reserved for proprietary list access commands. 



The S/R bit shall always be set to 1'. Use of value '0',"Rejection of message", as described in EN 300 175-5 [5], 
clause 7.7.23, is not foreseen in the present document as dedicated commands/codes exist to handle list access error 
cases. 

The command subfield indicates the identifier of the used command (as a message) and therefore identifies the structure 
of the following command specific bytes. The possible command identifiers are listed at the beginning of 
clause 7.4.10.4. 

Command as a complete exchange. A complete exchange between the PP and the FP makes use of several related 
commands (as a message) and is also called a command. The following types of commands (as a complete exchange) 
are used in the list access feature: 

1) <Command> from PP to FP, <Command confirmation> from FP to PP. 

2) <Command> from PP to FP, <Negative acknowledgement from FP to PP 

3) <Command> from PP to FP, <Command confirmationxdata packet>*<data packet last> from FP to PP 

4) <Commandxdata packet>*<data packet last> from PP to FP, <Command confirmation> from FP to PP 

5) <Commandxdata packet>*<data packet last> from PP to FP, <Negative acknowledgement from FP to 
PP 

NOTE 2: The star symbol ('*') is used above to indicate a possibly empty sequence of instances of the preceding 
command (as a message). 

A command (as a complete exchange) is named after the first command (as a message) used in the exchange (that is, 
after <Command>). Commands (as a complete exchange) are defined from clause 7.4.10.4.1 on. Type 2 or 5 is used 
when a command fails. 
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Table 38a: Summary of command types used by LiA commands 



Command 


Main 


Other 


Comments 


(complete exchange) 


type 
used 


possible 
types 




start session 


1 


none 


No negative acknowledgement is used as the start session confirm 
contains a start session reject reason subfield 


end session 


1 


none 


k i i ■ i it . 'ii 

No negative acknowledgement possible 


query supported entry 
fields 


1 


2 


Type 2 is used in case of error 


read entries 


3 


2, 1 


Type 3 is used if at least one entry exists in the requested range 
Type 2 is used in case of error (including if no entry is found) 
Type 1 is used if no field was requested (mark entries request only) 


edit entry 


3 


2 


Type 3 is used in case of success (including if some of the requested fields 
ids — but not all — are unknown to the FP) 

Type 2 is used in case of error (including if all field ids are unknown) 


save entry 


4 


5 


Type 4 is used in case of success. 

Type 4 (and not type 1) is also used if the 'edit entry' command was used, 
but without modification ('save entry' then contains a single empty data 

1 it 1 1 | ■ i || i | ■ \ 

packet last and its only purpose is to unlock the entry). 
Type 5 is used in case of error (including if at least one saved field id is 
unknown). The command may still be partially executed on some fields 
(best effort mode) 


delete entry 


1 


2 


Type 2 is used in case of error 


delete list 


1 


2 


Type 2 is used in case of error 


search entries 


3 


2, 1 


Type 3 is used in case of success (with at least one entry found). 
Type 2 is used in case of error (not finding any entry is not an error) 
Type 1 is used if no entry is found 


read selected entries 


3 


2 


Type 3 is used in case of success (with at least one entry found). 
Type 2 is used in case of error (including if no entry is found) 


write entry 


4 


5 


Command is never used with an empty data packet last (contrary to save 
entry). 


NOTE: Read entries and Search entries behave differently when no entry is found; Read entries considers this as an 
error, while Search entries does not (and answers with Type 1 : counter=0 and no data packet) 



Command overlap forbidden. The PP shall not overlap commands (as a complete exchange). In other words, the PP 
shall wait for the complete exchange to be terminated before initiating a new complete exchange. 

In the case where the FP nevertheless receives an overlapping command (as a message), it shall not crash. It may either 
answer it or ignore it. It shall not answer it with a negative acknowledgement for the reason of being overlapping. 

NOTE 3: An overlapping command may be answered with a negative acknowledgement if the command itself 
requires it (for another reason than being overlapping a previous command). 

In the case where the FP ignores an overlapping command, it shall also ignore all subsequent commands overlapping 
the same initial command (if any). 

NOTE 4: Not doing so would prevent the PP from mapping commands with answers. 

List access session. Access to a list is encapsulated in a session. Each session is linked to exactly one list access and is 
used: 

• by the FP to grant access to a list; 

• to handle accesses to multiple lists from one PP (one session per accessed list is used). 

Sequences of commands. Typical sequences of commands (as a complete exchange) between start and end of a session 
are the following: 

• "Read entries" or "Search entries", for just reading entries (see note 5). 

• "Read entries" or "Search entries" followed by "Edit entry" and "Save entry" for updating an existing entry, if 
an "Edit entry" has been issued but the list entry is left unchanged, a "Save entry" command shall still be used 
to unlock the entry (see notes 6 and 7). 

• "Save entry" with entry id equal to 0, for creating a new entry in the list. 
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NOTE 5: When allowed for a given list (see table 42) "Search entries" command may be used by a PP instead of 
"Read entries" command. 

NOTE 6: PP should perform a "Read entries" or "Search entries" before "Edit entry" so that the PP gets the "entry 
identifier" of the entry to be edited. This is especially valid when user accesses a list before modifying 
one entry or field of an entry. 

NOTE 7: "Read entries" or "Search entries" may be omitted by the PP before "Edit entry" in some specific cases. 

For example when the list has one single entry (i.e. DECT System Settings List) or a limited number of 
entries (e.g. Line Settings List) and if PP edits an entry without user interaction. 

Entry identifier: 

Each entry in a list is unambiguously identified within the FP for a dedicated list by an entry id. This entry id has to be 
referenced in case of writing access and is also used by the FP to reject multiple write accesses from several PPs. 

Field identifier: 

Each entry of a list may contain several fields. Each field has a unique identifier which is list dependent (see 
clause 7.4.10.5). This means the same field may be included in several list but with a different field id. This shall be 
taken into consideration when using field id in a command. 

Field instances management: 

Most of the time, the FP supports only one instance of a given field in a given list. However, for some fields in some 
lists, the FP supports several instances of the same field (same field id) in a given entry. The concerned fields and 
corresponding lists are the following: 

• Field 'Contact number' in the Contact List (see clause 7.4.10.5.1.11). The FP shall support at least two 'Contact 
number' field instances for all entries in the Contact List (i.e. the maximum number of instances supported 
shall be greater or equal to 2). Different contacts may have different numbers of 'Contact number' field 
instances. See clause 7.4.10.5.7. 

• Field 'Blocked number' in the Line Settings List (see clause 7.4. 1 1 .4.7). The FP may implement several 
'Blocked number' field instances in every entry of the Line Settings List. 

• Field FP IP address / DNS server' in the DECT System Settings List (see clause 7.4.1 1.3.8). 

The PP may use the 'Query supported entry fields' command (see clause 7.4.10.4.2) in order to be informed of the 
maximum number of instances supported by the FP for a field. 

Available instances. Instances held by the FP in a given entry are called available instances. There may be less 
instances available in a given entry than supported by the FP. Different entries may hold different number of instances 
for the same field. 

However, there shall be at least one available instance for each implemented field (n available — 1)- If there are no data 
currently associated with the field, this instance shall be empty. Empty field (instances) are defined in clause 7.4.10.5.1. 

NOTE 8: This empty instance needs not be actually stored by the FP, but has to be present over the air. Apart from 
this specific case, available instances are always non-empty (see clause 7.4.10.4.5.1, "Save entry" 
command). 

NOTE 9: When the FP supports a maximum of one instance for a field, this single instance is therefore always 
available. 

EXAMPLE 1 : An instance shall always be available for the following single-instance fields, although there may 
be no defined value for them at a given point in time (empty instance used): 

'Number' field in call lists, when the number is not known. 

'Dialling prefix', when no dialling prefix has been defined by the user. 

Ordering of instances. The FP shall respect the order of instances received from the PP at all times: at entry creation 
and at entry modification (and especially for instance deletion). This order of instances shall be respected over the air 
when the entry is requested again by one of the PPs. 
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NOTE 10: The PP may re -order instances when displaying them on its MMI. This re -ordering does not imply any re- 
ordering of the instances on FP side, unless the PP specifically requires this through a subsequent save 
command. 

NOTE 1 l:In order to delete an existing instance, the PP uses the 'Save entry' command. See clause 7.4.10.4.5. 

Requesting entries. When requesting entries (i.e. when using 'Read entries', 'Search entries', or 'Edit entry'), the PP 
specifies the number of instances requested {n re q Uestec j} for a given field by repeating the corresponding field id as 

many times. The PP may request any number of instances for a field (n re q Ues ted G [0> °°D- The FP shall ignore the 
field id occurrences exceeding the number of instances it supports. 

EXAMPLE 2: A PP could always request as many instances of the field as it is able to handle on its MMI. This 
number may exceed the maximum number of instances supported by the FP for the field. 

The FP shall answer in the command confirmation with available instances, in the order they are stored on FP side. If 
there are less instances available on FP side than requested by the PP (« aV az7afr/e < n requested) tne ^ s h au answer 
with all instances available; Otherwise (i.e. if « avaJ 7 a fr/ e > n requested)> shall answer with the first n re q Uested 

instances. 

NOTE 12:If n received is the number of received instances, n received = rmn(n available , n requested ). 

Saving existing entry. When saving an existing entry, the PP shall send at least all n rece i ved instances received during 

the previous edit entry confirm answer (with possible modifications or deletions). If n rece ^ ved < n re q Uested , the PP may 

save more instances than received (thus adding extra instances). However, the total number of saved instance shall 
never exceed the number of requested instances. 

NOTE 13:This can be summarized as: n received < n saved < n requested 

NOTE 14: This only applies if the PP saves the field. Otherwise, n saved = 0. In other words, if no modification is 

done by the PP on any instances of a field, all instances of the field should be simply omitted by the PP in 
the save. 

EXAMPLE 3: As a consequence, a non-editable field or field instance shall never appear in the 'save entry 

command'. Otherwise, a 'Procedure not allowed' negative acknowledgement shall be used by the 
FP. See clause 7.4.10.4.5. 

Saving new entry. When creating a new entry, the PP may send any number of instances. The FP shall discard instances 
exceeding the maximum number of instances it supports. 

NOTE 15:However, the PP should use the 'Query supported entry fields' command (see clause 7.4.10.4.2) in order 
to avoid handling and sending more instances than supported by the FP for the field. 

List index: 

The list index determines the position of an entry in a sorted list and is used for navigation within a list during a given 
List Access session. The list index associated to a given entry may change within a session after modification of the list 
and from one session to the next. 

For any list, the first index value used shall always be 1. The last index value shall be equal to the number of entries in 
the list. 

In order to indicate list changes to the PPs, a notification procedure is defined. This enables the PP to read list contents 
in advance before using them (caching), enabling the PP both to hold local copies of lists and to anticipate operations 
around the current entry, in order to save time and so increase interactivity (faster MMIs on PP side). 

Bytes order: 

When characters are transported in the «IWU to IWU» information element, the most significant byte shall be sent 
first. For example, character with code point U+00A2 is coded in UTF-8 as 'C2'H A2'H and conveyed with 'C2'H as the 
most significant byte. 
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Guarantee of service: 

When the FP supports a list, it shall manage and process all mandatory commands. See table 41 in clause 7.4.10.4 for 
details. Negative answers are allowed only for real faulty cases and shall not be used systematically. Especially, the FP 
shall not declare it supports a list and respond with negative answers to all commands. 

When a PP supports a list, the PP shall provide to the user all mandatory commands described in table 40 of 
clause 7.4.10.4. 

When the FP supports a list, the FP shall implement all fields of this list as defined in clause 7.4.10.5. For DECT 
System Settings List and Line Settings List, the status of the fields are given in table 9 (see clause 6.10). The FP shall 
have the capability to store and retrieve these fields to the PP. The defined structure of list entries describes the way 
they are exchanged over the air, and it does not necessarily mean this is the way they are actually stored in the FP 
memory. For example, the line name does not need to be stored for each entry in the FP (because it can be retrieved 
from the line id), although it has to be present in each entry if the field exists for the list and is requested by the PP. 

Each field has to be in each list entry at least once (a field may also be included more than once in each entry of the 
list). All entries of a list shall include the same fields. The PP may read, edit and save only some of the fields of entries 
of these lists (see each command in clause 7.4.10.4 for details). 

EXAMPLE 4: A PP may request the fields of an entry in two steps. In a first step, the PP only requests a subset of 
the fields (but for several entries) to allow the user to browse the list. In a second step, when the 
user actually selects one of the entries, the PP requests all the fields, but for the selected entry only. 

EXAMPLE 5: A PP may not request the line name field, as soon as it is able to display it: the PP could retrieve 
this field from the Line Settings List thanks to the line id (changes to the Line Settings List are 
notified to the PP, see clause 7.4.10.2.2). 

The FP always remains the master of the entry fields that are available in a list (number of fields per entry remains 
always the same and statically defined by FP). These fields cannot be removed nor added from the list by any PP (they 
can only be eventually reset by the PP). This is also valid when a field is included more than once in all entries. 

When the FP supports a field of an entry, it shall support as many values as possible for the field and process this field 
correctly. For example: if the FP uses a name entry field it shall fill it correctly and not always leave it empty. 

When the NG-DECT Part 3 system supports a list, it shall also implement the corresponding service related to this list, 
entry or field. The PP shall display as many fields as possible (see clause 7.4.10.5 for details on each list). 

The FP shall update the Missed Calls List, the Outgoing Calls List and the All Calls List by adding locally 
corresponding entries in the lists, and ensure the consistency of these lists (using the same field values for the same call 
if appearing in different lists). 

Display and edition of string fields: 

Both the PP and FP shall work in best effort mode. Meaning: do their best with their display capability, edit and storage 
capacities on each side independently. 

If PP saves or edits a longer string than the FP is able to store, the FP shall store only the first characters of the saved 
string (the FP shall truncate it). 

The PP will be aware of the truncation only when reading/editing the string a second time. 
If the PP edits a string that is longer than its display capability: 

• The PP may display to the user, edit and save the complete string by scrolling (recommended behaviour). 

• The PP may display, edit and save only the first characters, compatible with its display capability (fall back 
mechanism to be used if recommended behaviour is not implemented). 

Alphabet compatibility: 

List entry fields with characters shall in the FP be stored in UTF-8 format. 

PP shall support at least IA5 characters, and shall understand UTF-8 encoding format. 
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PP should not modify UTF-8 characters that it does not support, unless the character is edited by the user (e.g. replaced 
with a character supported by the PP). 

Additionally, the PP should follow the guidelines given in clause 7.4.17.2 ("display of UTF-8 characters on PP side") 
for the display of UTF-8 encoded characters. 

Initial values: 

• First possible session identifier assigned by FP shall be "1". Value "0" is a reserved return value used by the 
FP when a problem occurs. 

• First possible "list identifier" shall be "0" (see clause 7.4.10.3 for list identifier coding). 

• First possible "entry identifier" assigned by FP shall be "1". 

• First possible "field identifier" shall be " 1 " . 

• First possible "Start index" parameter value in 'Read entries confirm' and 'search entries confirm' commands 
shall be "1". Start index may be equal to in 'Read entries' command to point on the last entry. 

• First possible "position index" parameter value in save confirm command shall be "1" (first entry). 
Sessions: 

FP side: The number of simultaneous sessions is left free to FP implementation. However, the FP shall fulfil the 
following minimum requirements: 

• The FP shall be able to handle 2 started sessions initiated from a single PP at the same time on two different 
lists. 

• Once the maximum number of sessions is reached in the FP (for different lists or the same list) the FP shall 
issue a dedicated error code for any further start sessions attempts (in the start confirm see clause 7.4.10.4.1.2). 

NOTE 16: A simple FP implementation could be to support only 1 started session at a time for a given list (to avoid 
potential collision scenario). Another dedicated start session confirm error code exists for this. However, 
the list access protocol fully allows to support multiple sessions started over the same list. 

PP side: The number of simultaneous sessions is left free to PP implementation. 

NOTE 17:However it is recommended that the PP allows to save a number from a call list into the Contact List. 

Depending on the PP implementation, support of 2 simultaneous sessions could be convenient for this. 

All sessions between a PP and FP are ended at the latest at call release. 

The number of entries allowed within a list is defined by the FP (manufacturer dependent). A dedicated error code shall 
be used if PP tries to save new entry in a full list. 

Handling of collision scenario when a FP allows several PPs to access the same list simultaneously: 

• It is recommended that the second start session uses the same sorting criterion as the first start session. 
(However, FP will decide the final sorting criteria in start confirm and will probably re -use the same sorting 
criteria as the first started session). 

• The FP shall send list change notifications upon changes in this list (see clause 7.4.10.2). 

• No collision occur while both PPs perform only read entries / search entries commands. 

• One PP may be marginally un-synchronized concerning the content of one entry if the other PP modifies this 
entry (with edit+save). However, PP will be re-synchronized at its next read entries /edit entry/search entries 
command. 

• One PP may be temporarily un-synchronized from the list if the other PP deletes, creates (with save) an entry 
or deletes the list (cases where the total number of entries or position index of some entries are modified). 
Existing error codes for later "edit entries", "read entries" / "search entries" prevents potential problems. PP 
will be fully re-synchronized only when performing the next start session command, (see clause 7.4.10.2 for 
details). 
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• Edit entry command prevents severe collisions by locking an entry (relying on entry id and not position index). 

• The FP should carefully assign new entry identifiers when creating an entry (see clause 7.4.10.4.5.1). 
Guarantee of interactivity for the user: 

In order to guarantee a reasonable interactivity for the user: 

• The FP should optimize its implementation to process search and read commands. More precisely: 



For any 'Read entries' or 'Search entries' command in general (that is, involving any number of data 
packets), the total response time for the complete exchange should be as optimized as possible. 

For any 'Read entries' or 'Search entries' command answered by the FP with a single 'data packet last' 
(with no 'data packet' before), the total response time shall not exceed P100 (see clause A.4). This 
requirement only applies if the read or searched list resides locally in the FP. 



NOTE 18: A non-optimal implementation of the FP could use a'data packet' followed by a 'data packet last', even 
though the answer is short enough to fit in a 'single data packet last'. The above requirement still applies 
to such an implementation. 

NOTE 19:The latter case with a single 'data packet last' corresponds to the most common optimized browsing use 
case (e.g. of call logs, etc.). However, a business application storing some lists in a common remote 
database does not need to comply with response time requirements for these lists. 

• The PP should avoid using the 'Query supported entry fields' command systematically before any command, or 
when requesting only mandatory fields; this especially applies for lists with only mandatory fields. 

• The PP should avoid requesting a large number of entries or data especially if this request blocks the PP user 
interface (e.g. the PP should avoid requesting 50 entries in one read command if this request also blocks the 
user interface of the PP). 

• The PP should offer a way to the user to interrupt the list access session if requested by the user (i.e. by 
sending a {CC-RELEASE} if the received data packet transfer is very long). The FP shall handle 

this {CC-RELEASE} as soon as possible. 



The present 'List change notification' procedure describes the use of the 'list change indication' type of generic events 
notification (see clause 7.7.55 of EN 300 175-5[5]). It is potentially usable with any of the lists described in 
clause 7.4.10.5, but: 

• Clause 7.4.10.2.2 enumerates the lists for which the present procedure makes a 'list change indication' 
mandatory. Use of the procedure for other lists is optional and may not be relevant. 

• The Missed Calls List does not use the list change notification procedure (see clause 7.4.10.2) for the sending 
of list change indications. The procedure 7.4.1.3 'Missed call notification' describes all uses of a 'list change 
indication' for the Missed Calls List. 

Line identification used in a 'list change indication': As a general rule: 

• If the list contains a line identifier field, a 'line change indication' shall contain a line identifier, specified in a 
«CALL INFORMATION» IE. The line id to be used is described below (see 'Events triggering the 
notification' clause). 

• If the list does not contain any line identifier, the list change indication shall NOT contain any 
«CALL-INFORMATION» IE. 

Event multiplicity: The <event multiplicity> field shall contain: 

if a line id is specified: the total number of entries in the list for the specified line id 



7.4.10.2 



List change notification 



7.4.10.2.1 



General rule 
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if NO line id is specified: the total number of entries in the list 
at the time the notification is sent. More specifically, in the first case: 

• If the specified line id subtype 'Line identifier for external call' or 'Relating to' is used, the entries with 'All 
lines' value shall not be counted. 

• If the specified line id subtype is 'All lines', only entries with this subtype shall be counted. 

NOTE 1 : As a result, if one entry of the Line Settings List is modified, a list change notification is sent with the 
event multiplicity value set to 1, together with a «CALL INFORM ATION» IE set to 'Relating to' 
subtype and the line identifier value (see also clause 7.4.10.2.2). 

Events triggering the notification: When the present List change notification' procedure is implemented by the FP for 
a list, the following event types shall trigger a 'list change indication' from the FP. For each event type, the line to 
specify (if any) and the set of PPs receiving the notification (targeted PP or PPs) are indicated. 

• Entry created, modified, or deleted. If an entry in the list is created, modified or deleted, a 'list change 
indication' shall be sent. 

NOTE 2: Decision by the FP to change the "editable" property value of at least one field in a list is considered an 

entry modification. The "list change notification" is sent as soon as at least one entry exists in the list with 
a field instance concerned by the change. See annex H for more information. 

Specified line (only if the list contains a line identifier field): The line id subtype used, and the value used 
(if any value) shall be those of the concerned entry. 

NOTE 3: If the line id subtype 'All lines' is used, the line id value field is absent. 

Targeted PPs: At least all PPs attached to the specified line: 

■ If the concerned entry relates to a single line (line id subtype Line identifier for external call' or 
'Relating to'), the notification shall be sent to all PPs attached to the corresponding line. 

■ If the concerned entry contains a line identifier field with All lines' subtype, the notification shall 
be sent to all registered PPs (and shall contain the All lines' line id subtype, as already stated 
above). 

NOTE 4: The Contact List may use both types of targeted PPs, depending on the concerned entry. 

■ If the list does not containing any line identifier field, the targeted PPs shall depend on the list and 
on the context (see clause 7.4.10.2.2). 

• Base reset: If the FP is reset, a 'list change indication' shall be sent once for each line. 

NOTE 5: If a list is lost (i.e. erased from memory) as a result of the base reset a 'list change indication' is sent with 
<Event multiplicity> field set to '0'. 

Specified line (only if the list contains a line identifier field): Line for which the notification is sent (once 
for each line). 

Targeted PPs: At least all PPs attached to the specified line. 

NOTE 6: The purpose of this notification is re-synchronize the PPs with the lists state, in the case where the lists 
have changed during the base reset. 

• Location registration: A 'list change indication' shall be sent after location registration, once for each line the 
PP is attached to (1 FACILITY message per line the PP is attached to). 

Specified line (only if the list contains a line identifier field): Line for which the notification is sent (once 
for each line the PP is attached to). 

Targeted PP: The PP performing location registration (and only this PP). 
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NOTE 7: A location registration request ({LOCATE-REQUEST} message) is sent by the PP when the handset is 
switched on. A location registration request could be sent by the PP when it goes back in range (after it 
got out of range) in order to inform the FP that it may have lost some notifications. 

Almost simultaneous events: Several events (i.e. list changes) occurring almost simultaneously may be the subject of a 
single notification, provided the following rules are respected: 

1) all events notified together shall occur on, or concern, the same list; 

2) all events notified together shall occur on, or concern, the same line (same line id subtype and value). 

Notifications shall be sent by the FP by use of the "generic event notification" procedure. For indication of list change 
and values used in «Events notification» information element, consider table 39. 



Table 39: Values used within {FACILITY} message for list change indication 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 


<Event type> 


3 


List change indication 


<Event sub type> 


All 


List identifier as indicated in 
clause 7.4.10.3 


<Event multiplicity 


0..127 


Total number of entries in the list 
(see note 1) 


«Call lnformation» 






See note 2 


identifier type> 





Line identifier 


identifier sub type> 


'Line identifier for 
external call', 'Relating 
to', or 'All lines' 


The 'None' value is excluded 


identifier value> 


All 


The line identifier value itself if 
present 

(absent if 'All lines' subtype is used) 


NOTE 1 : 'Event multiplicity' can be extended for values up to 16 383 by using the following extension mechanism: If 
the bit at bit position 8 of the first octet is set to then a second octet will follow, if this bit is set to 1 then 
no further octet will follow. For values greater than 127 the first octet contains the 7 most significant bits 
and the bit at bit position 8 is set to whereas the second octet contains the 7 least significant bits and 
the bit at bit position 8 is set to 1 . For values below 128 the first octet contains the 'Event multiplicity' value 
and the bit at bit position 8 is set to 1 indicating that no second octet will follow. Examples: decimal value 
1 28 is coded as 01 H 80H, decimal value 1 7 is coded as 91 H and decimal value 1 is coded as 81 H. 

NOTE 2: «Call information» only present if list change indication is related to one or more lines. 



7.4.10.2.2 Mandatory notifications 

In order to allow the display of information in idle mode on PP side, notifications shall be sent by the FP for the 
following lists: 

• Line Settings List (defined in clause 7.4.1 1.4). As indicated in clause 7.4.10.2.1, changes in an entry of this list 
shall be notified to all PPs attached to the line identified by the field Line id' of that entry. However for fields 
which are optional or which do not require the PP to update its user interface, notification is optional or 
irrelevant (see clause 7.4.1 1.4). 

NOTE 1: This allows in particular the PP to immediately update the line name in other lists entries (e.g. if used 
instead of the line id when the list is presented to the user). 

• Internal Names List. A change in this list shall be notified when a PP modifies the name of another PP (if the 
FP allows it), and the list change notification shall at least be sent to that other PP concerned by the change. 
Furthermore the FP shall send a list change notification to all PPs if a PP has been added to this list (e.g. as a 
result of a registration) or removed from this list (e.g. as a result of a de -registration). 

For all other lists, sending of notifications is left free to the implementor. However, the possibly important extra 
processing on FP and PP sides necessary for sending and handling notifications (e.g. if sent for each call) shall be 
carefully taken into account. 

NOTE 2: The present List change notification' procedure cannot be used for the Missed Calls List as stated in 
clause 7.4.10.2.1. 
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7.4.1 0.3 List identifier codings 

The following list identifier codings are defined: 



87654321 


Meaning 


00000000 


List of Supported Lists 


0000000 1 


Missed Calls List 


000000 1 


Outgoing Calls List 


000000 11 


Incoming Accepted Calls List 


00000 100 


All Calls List 


00000 10 1 


Contact List 


00000 110 


Internal Names List 


00000 1 1 1 


DECT System Settings List 


0000 1000 


Line Settings List 


0000 100 1 


All Incoming Calls List 


1 xxxxxxx 


Reserved for proprietary lists 



all other values reserved 

The lists shall be sorted on the FP, using default criteria for each of them. The default sorting criteria are the following: 

• The Missed Calls List, Outgoing Calls List, Incoming Accepted Calls List, All Incoming Calls List and more 
generally all call related lists shall be sorted by default using the "Date and time" field. 

• The Contact List shall be sorted by default using the "Name" field (first criterion). When the names are equal 
the list should be sorted using the "First name" field (criterion 2). 

• The Internal Names List shall be sorted by default using the "Number" field (terminal id number). 

• The Line Settings List shall be sorted by default using the "Line id" field. 

• The DECT System Settings List and List of Supported Lists are not sorted by default as they contain only one 
entry. 

Please refer to the "Start session" command for a definition of the sorting order used for a given field type (this 
definition applies independently of the position of the field in the sorting process: i.e. whether used as "first criterion", 
"criterion 2", etc.). 

7.4.1 0.4 List Access Commands 

The following list access commands are defined: 



87654321 


Meaning 


PP -> FP 


FP -> PP 


00000000 


start session 


yes 




0000000 1 


start session confirm 




yes 


000000 10 


end session 


yes 


yes 


000000 11 


end session confirm 


yes 


yes 


00000 100 


query supported entry fields 


yes 




00000 10 1 


query supported entry fields confirm - 


yes 


00000 110 


read entries 


yes 




00000 1 1 1 


read entries confirm 




yes 


0000 1000 


edit entry 


yes 




0000 100 1 


edit entry confirm 




yes 


0000 1 1 


save entry 


yes 




0000 10 11 


save entry confirm 




yes 


0000 1100 


delete entry 


yes 




0000 110 1 


delete entry confirm 




yes 


0000 1110 


delete list 


yes 




0000 1 1 1 1 


delete list confirm 




yes 


000 10000 


search entries 


yes 




000 1000 1 


search entries confirm 




yes 


000 100 10 


negative acknowledgement 




yes 


000 100 11 


data packet 


yes 


yes 


000 10 100 


data packet last 


yes 


yes 
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lxxxxxxx reserved for proprietary list access commands 
All other values reserved 

Proprietary list access commands shall have list access command codings with most significant bit set to T. 

The "read entries", "read entries confirm" and "search entries confirm" commands use a start index as these command 
may apply to a range of entries within a list. 

The "save entry confirm" command uses a position index as this command applies to one entry. 

Possible error codes are specified for each command from PP to FP. They use negative acknowledgement command, 
with exception of negative start session confirm. 

Additionally to the general status of a given command and a given list as described in table 9 for feature [NG1.N.16], 
the PP shall follow the following more detailed requirements: 



Table 40: PP commands support status per list 



List (with status as given in 
table 9, feature [NG1.N.16]) 


Command (with status as given in table 9, feature [NG1.N.16]) 




Start/end 


Query 


Read 


Edit 


Save 


Delete 


Delete 


Search 




session 
(M) 


supported 

entry 
fields (0) 


entries 
(M) 


entries 
(M) 


entry (M) 


entry 
(M) 


list (M) 


entries (M) 


Lists of supported lists (0) 


M 


I 


M 


I 


I 


I 


I 


I 


Missed Calls List (M) 


M 





M 


I (note 1 ) 


I (note 1 ) 


M 


M 





Outgoing Calls List (O) 


M 





M 


I 


I 


M 


M 





Incoming Accepted Calls List 
(M) 


M 





M 


I 


I 


M 


M 





All Calls List (0) 


M 





M 


I 


I 


M 


M 





Contact List (M) 


M 





M 


M 


M 


M 





M 


Internal Names List (M) 


M 





M 


M 


M 


M 


I 





All Incoming Calls List (0) 


M 





M 


I 

(notes 
1 &2) 


I 

(notes 
1 &2) 


M 


M 





DECT System Settings List 
(M) 


M 





M 


M 


M 


I 


I 


I 


Line Settings List (M) 


M 





M 


M 


M 





I 


I 


NOTE 1 : The command may however be used for editing the 'Read status' field (and only that field). The 'Read status' 
field is the only editable field in this list (see annex H). Other fields of the list may however be present in the 


edit entry. 

NOTE 2: For the All Incoming Calls List, the Read status field is only used (and is only editable) for missed calls. 



EXAMPLE: If the PP implements the List of Supported Lists (optional list), PP shall then implement 'start 
session', 'end session' and 'read entries' commands, other commands for this list are irrelevant. 

Additionally to the general status of a given command and a given list as described in table 9 for feature [NG1.N.16], 
the FP shall follow the following more details requirements. 
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Table 41 : FP commands support status per list 



Llbl ^Wllll bldlUb as given IN 

table 9, feature [NG1.N.16]) 


Command (with status as given in table 9, feature [NG1.N.16]) 




OLdl 1/ ci 1U 

^p^inn 
(M) 


uuci y 
^unnnrtpd 

entry 
fields (M) 


ncdU 

pntrip^; 
(M) 


cull 
pntrip^ 

Cllll ICO 

(M) 


Odvc 

pntrv f Wh 

d III V y ■■■ f 


Do Iota 
pntrv flUh 

i ii y y ivi j 


Utricle 

list (M\ 

noi y ivi j 


Ot2dlL.ll 

pntrip^ ^M^ 

ci ill iv<9 y iviy 


Lists of supported lists (M) 


M 


1 (note 1 ) 


M 


I (note 1 ) 


I (note 1) 


1 (note 1) 


I (note 1 ) 


I (note 1 ) 


Miqqpd Calk I i<?t IM) 

IvMCJOCU W all O LloL V / 


M 


M 


M 


I (note 5) 


I (note 5) 


M 


M 


M 


Ontnninn Calk I fO^ 

\_/u ty kj 1 1 ly w d m o lioi 


M 


M 


M 


I (note 1 ) 


I (note 1) 


M 


M 


M 


Incoming Accepted Calls List 
(M) 


M 

IVI 


M 
IVI 


M 
IVI 


I fnnto 1 
I ^i lULc 1 ) 


1 fnnto 1 ^ 
I \\ lulu I ) 


M 

IVI 


IVI 


IVI 


aii p^iiq i iQt /T^ 


M 


M 


M 


1 (note 1) 


I (note 1) 


M 


M 


M 


Contact List (M) 


M 


M 


M 


M 


M 


M 


M 


M 


Internal Names List (M) 


M 


M 


M 


M (note 4) 


M (note 4) 


M (note 4) 


I (note 1 ) 


M 


All Incoming Calls List (0) 


M 


M 


M 


I (notes 5 
and 6) 


I (notes 5 
and 6) 


M 


M 


(note 2) 


DECT System Settings List (M) 


M 


M 


M 


M (note 4) 


M (note 4) 


I (note 1) 


I (note 1 ) 


I (note 1 ) 


Line Settings List (M) 


M 


M 


M 


M (note 4) 


M 

(notes 3 
and 4) 


O 

(notes 2 
and 4) 


I (note 1 ) 


I (note 1 ) 


NOTE 1 : FP shall answer with negative acknowledgement / 'procedure not allowed'. 

NOTE 2: If not supported, FP shall answer with negative acknowledgement / 'procedure not allowed'. 

NOTE 3: FP shall support the command to offer the possibility to modify a line setting. However, the 'save entry' for 

creating a new line may not be supported by the FP. See clause 7.4.10.4.5.2. 
NOTE 4: Additional requirements apply when a PP is involved in a voice call. FP shall temporarily restrict access to the 

list during the duration of the voice call. See clause 7.4.10.6 for details. 
NOTE 5: FP shall answer with negative acknowledgement / 'procedure not allowed' unless the command is used to edit 

the 'Read status' field only. The 'Read status' field is the only editable field in this list (see annex H). Other fields 

of the list may however be present in the edit entry. 
NOTE 6: For the All Incoming Calls List, the Read status field is only used (and is only editable) for missed calls. 



7.4. 10.4.1 Start and end session 

7.4.1 0.4.1 .1 "Start session" command 

This command from PP requests to start a session to access the specified list in the FP. 



Table 42: Values used within {IWU-INFO} message 
to request the starting of a list change session 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 


<S/R bit> 


1 


Transmission of message 


<Protocol Discriminated 


03H 


List access 


<Command =start session> 





List access command 


<List identifier 


0..FFH 


List identifier 


<Sorting fields> 




List of suggested fields for sorting 
the list towards this PP 


<Number of sorting fields> 


0..255 


If 0, the default sorting of the list shall 
be used by the FP (see note) 


<Sorting field identifier 1> 


0..255 


Suggested field element type used 
for sorting the list (first criterion) 








<Sorting field identifier n> 


0..255 


Suggested field element type used 
for sorting the list, to be used when 
field 1 , field n-1 of both compared 
entries are equal (criterion n) 


NOTE: It is recommended to limit the number of requested sorting fields to two (n=2). 
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The submitted sorting field identifiers suggest entry fields which should be used by the FP to sort the requested list 
towards this PP in the given session. This suggests to sort the list by "sorting field 1" as first criterion, and then by 
"sorting field 2" as second criterion, when field 1 of both compared entries are equal, and so on. 

For each field type, a sorting order is defined, which applies independently of the position of the field in the sorting 
process: i.e. whether used as "first criterion", "criterion 2", etc. The defined sortings are as follows: 

• For fields of type "Number" (including terminal id numbers), "Name", "Line name", "First name", or "Contact 
number", the case insensitive alphanumeric al order shall be used (see Figure 54a below with related note and 
following example). 

NOTE: The case insensitive alphanumerical order can only be defined on a subset of the UTF-8 encoded 
characters. This subset and the associated order depend on the locale used. 




NOTE: The 'case insensitive alphanumerical order' is not a full order. It does not define the order of values that are 
case insensitively equal, such as "SMITH", "Smith", "smith", as illustrated above. There are several ways for 
the FP to perform the final sorting and this final sorting is left free to the implementation. 

Figure 54a: Case insensitive alphanumerical order 

EXAMPLE 1: The full order for the example above could be implemented in the FP as follows: ALEXANDER, 
Alexander, BORDONADO, SMITH, Smith, smith, WALKER (i.e. case sensitive ordering is 
performed over case insensitively equal values only). 

• For fields of type "Date and time", the ante chronological order shall be used (highest index for the oldest call, 
lowest index for the newest call). 

• For fields of type "Line id", the ascending numerical order shall be used. 

If several instances of a field used for sorting are included in the list (see clause 7.4.10.1, entry 'Field instances 
management'), only one instance of this field shall be specified in the 'start session' and 'start session confirm' 
commands. The FP shall decide which instance of the field is used for the sorting. 

EXAMPLE 2: If the PP requests Contact List to be sorted with the contact number field and the list entries 

include one "mobile" and one "work" contact number fields, the FP may use the "mobile" instance 
of the field for sorting. Entries with "mobile" numbers may appear first in the list then entries with 
"home" numbers. Please note that this additional "sub sorting" performed by the FP might be 
unknown or a bit inconvenient to the user (on PP side). As a consequence, the PP should request 
such sorting only if strictly necessary. 

If the <Number of sorting fields> is equal to 0, the FP shall use the default sorting of the list. No sorting field identifier 
is sent in this case. 

When performing a 'Start session' command on the DECT System Settings List or the List of Supported Lists, the PP 
should request the default sorting (as those lists cannot be really sorted because they contain only 1 entry). 
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7.4.1 0.4.1 .2 "Start session confirm" command 

This command from FP to PP confirms or rejects the start of the session. 



Table 43: Values used within {IWU-INFO} message to confirm or 
reject the starting of a list change session 



Information element 


Field within the information 
element 


Standard values 
witnin tne Tieio/it 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminated 


03H 


List access 




<Command =start session 
confirm> 


1H 


List access command 




<List identifier 


0..FFH 


List identifier 




<Session identifier 


0..127 


Session identifier (see note 1) 




<Total number of available 


0..127 


Number of available entries in list 




entries> 




requested by the PP (see note 1) 




<Discriminator type> 


00H, 01 H 


Undefined, EMC (see note 2) 




<Discriminator> 


00H..FFH 


EMC value high byte 




<Discriminator> 


00H..FFH 


EMC value low byte 




<Start session reject reason> 


0..FFH 


Reject reason in the case of reject 




<Sorting fields> 




List of fields used for the actual 
sorting the list towards this PP 




<Number of sorting fields> 


0..255 






<Sorting field identifier 1> 


0..255 


Field element type used for the 
actual sorting the list (first criterion) 












<Sorting field identifier n> 


0..255 


Field element type used for the 
actual sorting of the list (criterion n) 


NOTE 1 : 'Total number of available entries' and 'session identifier' can be extended for values up to 16 383 by 


using the same mechanism as for 'Event multiplicity'. See note 1 at table 39. 


NOTE 2: Discriminator type set to '1 ' (= EMC) indicates the support of proprietary list access commands, of 
proprietary lists and of proprietary list fields. For distinguishing proprietary elements from different 
manufacturers, the EMC is given in the following two octets. In the case where Discriminator type is set to 


'0', the following two octets are do not care. The PP shall not use proprietary elements if either the 
Discriminator type is '0' (= Undefined) or the EMC is different from the own one. Proprietary elements 
shall have identifiers with the most significant bit set to '1 '. 



The session identifier shall be unique between the FP and one PP. It identifies the access to one list for the PP, which 
has started the session. The FP shall at least support two session at a time to one PP. 

The submitted list entry field identifiers are used to indicate the entry field which is used by the FP to sort the requested 
list towards this PP in the given session. The FP may choose other entry fields than the ones suggested by the PP in the 
'start session' command (e.g. 'name' instead of 'first name' in Contact List). The sorting capabilities of the FP depend on 
the implementation of the FP. 

For list entry field identifiers see clause 7.4.10.5.1. 

If start session is confirmed the reject reason shall not be evaluated. 

Even if the default sorting is required by the PP in the "Start session" command (using '0' as value for <Number of 
sorting fields>), the FP shall confirm the sorting fields which were actually used for sorting the list (and which shall be 
the ones defined as "default" sorting fields in clause 7.4.10.4.1.1). 

For the DECT System Settings List and the List of Supported Lists, the 'Number of sorting fields' shall be set to by the 
FP and no 'Sorting field identifier' shall be specified (as those lists cannot be really sorted because they contain only 1 
entry). 

Possible error cases: 

If start session is rejected, the session identifier shall be set to 0, and the field reject reason shall indicate the appropriate 
reason. 



ETSI 



165 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



If a sorting field identifier is not valid, the submitted sorting field identifier shall be ignored by the FP. Nevertheless the 
FP indicates the chosen sorting field identifiers in the start session confirm. 

Start session reject reason: 

Bits 87654321 Meaning 

00000000 not enough resources 

00000001 list already in use by another session 

1 list not supported 

0000001 1 maximum number of sessions supported by the FP reached 
All other values reserved 

If a FP allows only 1 started session for a given list (to avoid potential collision scenarios), the FP shall use the reject 
reason "list already in use by another session". 

If a PP attempts to start a session and the FP has no more resources to handle this start session, the FP shall use the 
reject reason "maximum number of sessions supported by the FP reached". 

7.4.1 0.4.1 .3 "End session" command 

This command from PP or FP ends the specified session. 



Table 44: Values used within {IWU-INFO} message 
to request the end of a list change session 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminated 


03H 


List access 




<Command =end session> 


2H 


List access command 




<Session identifier 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended for values up to 16 383 by using the same mechanism as for 'Event 
multiplicity'. See note 1 at table 39. 



This command is recommended to be sent by PP and FP to request end of session. 
The session(s) between a PP and FP shall at latest be terminated with call release. 

Remaining locked entries (see edit procedure) shall be unlocked either with the end session command or at latest with 
call release ({CC-RELEASE} message). 

Possible error cases: 

If session identifier is wrong the command should be ignored by the receiver. 
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7.4.1 0.4.1 .4 "End session confirm" command 

This command from PP or FP confirms the ending of the specified session. 



Table 45: Values used within {IWU-INFO} message 
to confirm the end of a list change session 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminated 


03H 


List access 




<Command =end session 
confirm> 


3H 


List access command 




<Session identifier 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended for values up to 16 383 by using the same mechanism as for 'Event 
multiplicity'. See note 1 at table 39. 



Reject of end session request shall not be possible. 

7.4. 10.4.2 Query supported entry fields 

7.4.1 0.4.2.1 "Query supported entry fields" command 

This command from PP queries the fields which are supported or not in the entries of a given list in the FP. 



Table 46: Values used within {IWU-INFO} message 
for the "Query supported entry fields" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator 


03H 


List access 




<Command = query supported 
entry fields> 


4H 


List access command 




<Session identifier 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended for values up to 16 383 by using the same mechanism as for 'Event 
multiplicity'. See note 1 at table 39. 



Possible error cases: 

If session identifier is wrong, the FP shall answer with negative acknowledgement reject reason 'invalid session 
number'. 

7.4.1 0.4.2.2 "Query supported entry fields confirm" command 

This command from FP confirms the query of supported fields which are supported or not in the entries of a given list 
in the FP. 

The FP submits the supported entry field identifiers and shall group them in editable and no editable fields. 

Belonging to the "editable" group shall only indicate that at least one instance of the field in one entry is liable to be 
editable: even when a field is indicated as editable in the "confirm", the PP shall be prepared to handle some instances 
of this field in some entries as non-editable. For example: 

in the Line Settings List, the "Line name" field could be protected against modification for some lines; 

in the Line Settings List, a given line could include a non-editable "Blocked phone number" field instance, 
while other instances of the field remain configurable for the user; 
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the Contact List could contain some non-editable entries (e.g. for emergency calls). 

NOTE 1: The reverse is not true: all instances of a field indicated as non-editable always remain non-editable in all 
entries in the current list access session. 



Table 47: Values used within {IWU-INFO} message 
for the "Query supported entry fields confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminated 


03H 


List access 




<Command = query supported 
entry fields confirm> 


5H 


List access command 




<Session identifier 


1..127 


Session identifier (see note) 




<number of editable entry fields> 


0..255 


Number of editable entry fields 




<List entry field identifier 1> 


0..255 


Supported field element type 












<List entry field identifier n> 


0..255 


Supported field element type 




<number of no editable entry 
fields> 


0..255 


Number of no editable entry fields 




<List entry field identifier 1> 


0..255 


Supported field element type 












<List entry field identifier n> 


0..255 


Supported field element type 


NOTE: 'Session identifier' can be extended for values up to 16 383 by using the same mechanism as for 'Event 
multiplicity'. See note 1 at table 39. 



When several list entry field identifiers are specified within the command, these field identifiers shall be ordered in 
ascending numerical order. 

As described in clause 7.4.10.1 ('Field instances management' entry), the FP may support several instances of a field 
(and up to a maximum number of instances). The maximum number of instances supported by the FP shall be notified 
to the PP in the 'Query supported entry fields confirm' by including the field id as many times as the maximum value. 

EXAMPLE: For a single-instance field, the field id shall appear once in the confirm. For a multiple instance 
field: if the FP supports '2' instances of the field, the field id shall appear twice in the confirm. 

NOTE 2: See clause 7.4.10.4.1, entry 'Field instances management' for more information on how this information 
can be used. 

For list entry field identifiers see clause 7.4.10.5.1. 

7.4.10.4.3 Read entries 

7.4.1 0.4.3.1 "Read entries" command 

This command from PP requests to read a range of consecutive entries in the list, or only a subset of the fields of these 
entries. The list here shall be understood as the list resulting from the initial sorting of the list as specified by the FP in 
the "Start session confirm" command. 

NOTE 1 : Range can be limited to one entry. 
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Table 48: Values used within {IWU-INFO} message for "Read entries" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 




L 


I pnnth nf nnntpnt 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminated 


03H 


List access 


<Command =read entries> 


cu 
on 


List access command 


<Session identifier> 


\ ..\ d. f 


Session identifier (see note 1 ) 


<Start index> 


U..1 tLl 


Start index (see note 1) 


<Direction (bit 8)> 
<Counter (bits 1 to 7)> 


n -\ 
1 ..127 


Direction of the read (forward or 
backward) 

Number of requested entries 


<Mark entries request> 


00H, 7FH, FFH 


Flag for requesting resetting (or 
setting) of the 'Read status' field for 
all read entries (see note 2) 


<List entry field identifier 1> 


0..255 


Requested field element type 








<List entry field identifier n> 


0..255 


Requested field element type 


NOTE 1 : 'Session identifier' and 'start index' can be extended for values up to 16 383 by using the same 

mechanism as for 'Event multiplicity'. See note 1 at table 39. 
NOTE 2: This field is used (with value 7FH) to indicate that the entries read by the PP are considered as read by 

the user, or will necessarily be read by the user. The <mark entries request> field is only considered if the 

list contains a 'Read status' field. Otherwise it is present but ignored on both sides. See also below 

subsection 'Mark entries request (octet)'. 
NOTE 3: 'List entry field identifier' values are defined for each list separately. 



Start index: 

The start index is the first index of the range of requested entries. 

Bits 7 6 5 4 3 21 Meaning 

last entry 
other values list entry 

Direction and Counter (octet): 

Bits 87654321 Meaning 

Oxxxxxxx forward (in ascending list index order) 

1 xxxxxxx backward (in descending list index order) 

The response contains data packets with list entries in order of ascending list index, regardless of whether counter 
indicated forward or backwards and always includes the entry with list index=start index. 

EXAMPLE: If 2 entries are requested 'backwards' with start index 5, the data packets shall include the entries 
with indices 4 and 5, with entry 4 transmitted first. 

Mark entries request (octet): 

This field applies to a list having a 'Read status' field, and is otherwise ignored on both sides. This field allows the PP to 
request from the FP that all read entries 'Read status' field be reset (when value '7F'H is used), or that all read entries be 
set (when value 'FF'H is used). Value '00'H indicates that the 'Read status' field for all read entries shall be left 
unchanged. 

NOTE 2: Only the Missed Calls List and the All Incoming Calls List have a 'Read status' field. For the All 

Incoming Calls List the mark entries request is only applied to missed call entries (incoming accepted 
calls have a fake 'Read status' field with a frozen value of '0'). 

When the value '7F'H or 'FF'H is used (mark all entries as read or as unread), the subset of requested fields may be 
empty. In that case the 'Read entries' command is only used by the PP to mark entries as read or as unread in the list. As 
a result, a 'Read entries confirm' command with no data packet shall be returned by the FP (see clause 7.4.10.4.3.2). 
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When the value 7F'H or 'FF'H is used, the possible modification of the 'Read status' field (entries marked as 'read' or 
'unread') will apply on the concerned entries after the last data packet related to the 'read entries confirm'. In other 
words, the 'Read status' field of the entries returned in the data packets is unchanged. The possibly modified 'Read 
status' field value will be reflected at the next 'read entries'/'search entries' command performed by the same PP or 
another PP. 



Bits 87654321 Meaning 

00000000 all read entries 'Read status' field shall be left unchanged 

01111111 all read entries 'Read status' field shall be reset (i.e. marked as read) 

11111111 all read entries 'Read status' field shall be set (i.e. marked as unread) 

All other values reserved 



This field allows the PP to follow various strategies when presenting entries to the user, including the following ones: 

• Single-step strategy (for simple PPs): the PP always use value 7F'H so that all entries read from the FP have 
always their 'Read status' field reset. 

• Enhanced two-step strategy ('Browsing then reading'). A PP using this strategy always uses value '00'H for 
browsing (typically reading only part of the fields in that step). When a user selects an entry to actually read it, 
the PP edits and then saves the selected entry in order to mark the entry as read. 

NOTE 3: The 'Read entries' command cannot be used in order to perform the second step, because this command is 
based on entry index, which could have changed between the two steps. 

NOTE 4: The detailed entry data presented to the user during the second step should be based on the data received 
during the 'edit entry confirm'. 

List entry field identifier: 

When reading entries, the PP specifies the requested fields by using 'list entry field identifiers'. For more information, 
see clause 7.4.10.1, 'Field instances management' entry. 

NOTE 5: A PP has to enumerate the field ids in the request even if it is requesting all fields. 

Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

If the 'start index' is invalid, the FP shall answer with negative acknowledgement, reject reason 'invalid start index'. This 
includes the case where the list is empty. 

If the index range given with 'counter' is invalid, the FP shall return the existing elements in the range. 

NOTE 6: In the case the 'Read entries' command was only used by the PP to mark entries as read or as unread in the 
list, the FP will mark the existing elements in the range. 

If an unknown list entry field identifier is requested, the FP shall ignore this field and continue with the next requested 
field. 
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7.4.1 0.4.3.2 "Read entries confirm" command 

This command from FP confirms the read command with the corresponding entry/entries with one or several specified 
fields. Corresponding entry/entries are sent along in data packets. 



Table 49: Values used within {IWU-INFO} message for "Read entries confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminated 


03H 


List access 




<Command =read entries 


7H 


List access command 




confirm> 








<Session identifier 


1..127 


Session identifier (see note) 




<Start index> 


1 ..127 


Start index (see note) 




<Partial delivery (bit 8)> 


0..1 


Partial delivery owing to FP memory 
limitation 




<Counter> (bits 1 to 7) 


0..127 


Number of actually delivered entries 


NOTE: 'Start index' and 'Session identifier' can be extended for values up to 16 383 by using the same 


mechanism as for 'Event multiplicity'. See note 1 at table 39. 





'Partial delivery' and 'Counter' (octet): 

The 'Counter' subfield (bits 1 to 7) contains the number of list entries that will be actually delivered in following data 
packets / data packet last. 

The 'Partial delivery' flag (bit 8) indicates (when set) that the FP can only partially carry out the request, owing to 
memory limitations (response too big). When setting this bit for limiting the response size, the FP shall always send 
entire 'entries' (i.e. not deliver only a part of an entry). 

The FP shall answer in the read confirm with one of the following four methods below: 

• 'Bit 8 = 0' and 'Counter = 0': the 'Read entries' request was successfully completed to mark entries as read or as 
unread in the list, and no data packet shall be sent (see also clause 7.4.10.4.3.1). 

• 'Bit 8 = 0' and 'Counter = Number of requested entries': the 'Read entries' request was successfully completed. 

• 'Bit 8 = 0' and 'Counter < Number of requested entries': the 'Read entries' request was successfully completed, 
but there were less entries available in the list than requested by the PP. 

• 'Bit 8=1' and 'Counter < Number of requested entries': the 'Read entries' request was only partially carried 
out, owing to FP memory limitation. The PP shall then perform one or several new 'Read entries' request(s) in 
order to get the remaining entries. 

NOTE 1: The number of requested entries is the value of the 'Counter' field in the 'Read entries' request. 

NOTE 2: Use of bit 8 (when set) is not considered as an error case and no negative acknowledgement is used. 

For performance reasons on PP side, the FP should be capable of delivering at least a few entries if requested by the PP. 
For example, the FP should be able to deliver at least 5 entries of any list. This allows a five-line display PP to display 
"one page" of list content via only one "Read entries" command. 

Bits 87654321 Meaning 

Oxxxxxxx Full delivery (bit 8 not set); Counter (bits 1 to 7) 
lxxxxxxx Partial delivery (bit 8 set); Counter (bits 1 to 7) 

If a given field is included more than once in the entries, all instances of this field shall be included in the "Read entries 
confirm" command. 

'Start index' shall always indicate the smallest index value of the list response. 
Content of list entry is transmitted in data packets. 
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7.4.10.4.4 Edit entry 

7.4.1 0.4.4.1 "Edit entry" command 

This command from PP requests to read and lock only one entry. 



Table 50: Values used within {IWU-INFO} message for "Edit entry" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator 


03H 


List access 




<Command =edit entry> 


8H 


List access command 




<Session identifier 


1..127 


Session identifier (see note) 




<Entry identifier 


1..127 


Entry identifier (see note) 




<List entry field identifier 1> 


0..255 


Requested field element type 












<List entry field identifier n> 


0..255 


Requested field element type 


NOTE: 'Session identifier' and 'entry identifier' can be extended for values up to 16 383 by using the same 
mechanism as for 'Event multiplicity'. See note 1 at table 39. 



A PP may edit some or all the fields of an entry (independently of whether the "editable" property of the field is set or 
not). Whether a field element is editable or not is indicated for each field in the response message (i.e. in the "editable" 
property of each field). 

In contrast to 'read entries', the "edit entry" list access command contains a reference to a single list entry ("entry 
identifier" field). 

When receiving an "edit entry" command, the FP shall prevent other PPs from changing the specified list entry 
(negative acknowledgement with reject reason 'temporarily not possible') until the sending PP has sent the 
corresponding "save entry" command, or until the session is terminated. In other words, the FP shall temporarily 
prevent "save entry" and "delete entry" commands for the entry from being used by other PPs, as well as the "delete 
list" command. 

'List entry field identifier' values are defined for each list separately. 

When several list entry field identifiers are specified within the command, these field identifiers shall be ordered in 
ascending numerical order. 

Possible error cases: 

Invalid session number: If session identifier is wrong the FP shall answer with negative acknowledgement reject 
reason 'invalid session number'. 

Entry not available: If an unknown entry identifier is requested, the FP shall answer with negative acknowledgement, 
reject reason 'entry not available'. 

Procedure not allowed: The FP shall answer with a negative acknowledgement with reject reason 'procedure not 
allowed' in the following cases: 

the FP does not allow the use of the 'edit entry' command for the list (see clause 7.4.10.4, table 41). 

all requested fields for the edited entry have unknown identifiers. 

EXAMPLE: An optional field on FP side that is not implemented by the FP is a kind of field with unknown 
identifier. If a single non-implemented field is requested in the edit entry, a negative 
acknowledgement shall therefore be returned. 

NOTE: However, a PP should use the 'Query supported entry fields' command (see clause 7.4.10.4.2) in order to 
avoid sending unimplemented fields to the FP. 

However, in the case where some — but not all — of the requested field identifiers are unknown, the FP shall ignore 
them and process the command as if it contained only the known fields. 
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7.4.1 0.4.4.2 "Edit entry confirm" command 

This command from FP confirms the edit command with the corresponding entry with one or several specified fields, 
and locks this entry against access from other PPs. Corresponding entry is sent along in data packets. 



Table 51 : Values used within {IWU-INFO} message for "edit entry confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminated 


03H 


List access 


<Command =edit entry confirm> 


9H 


List access command 


<Session identifier 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended for values up to 16 383 by using the same mechanism as for 'Event 
multiplicity'. See note 1 at table 39. 



Content of list entry is transmitted in data packets. 

When a non-editable field is requested by a PP, the FP shall return it. This is not considered as an error case, the 
"editable" property will indicate whether this field element is editable or not. 

If a field is included more than once in the entry, all instances of this field shall be included in the "edit entry confirm" 
command. 

7.4.10.4.5 Save entry 

7.4.10.4.5.1 "Save entry" command 

This command from PP requests to save the entry in the list identified by the specified entry identifier, or to add a new 
entry to the list. Corresponding entry is sent along in data packets. 

The list entries which are saved shall have been requested via 'edit' before in the same session, except for creation of a 
new entry. 

Saving of an existing entry: 

The 'save' transaction shall contain all fields or a subset of the fields which were submitted in the 'edit' transaction. 
Other fields (not edited, or edited but not saved) remain unchanged in the FP. 

For more information, see clause 7.4.10.1, 'Field instances management' entry. 

Best effort mode: 

When receiving the data packets following the 'save entry' command, the FP shall work in best effort mode: 

• Saving the new value (or instance values) proposed for all fields for which it is possible. 

• Not saving the new value (or instance values) proposed for a field if it is not possible, i.e. in the following 
error cases: 

'PIN code required' error case for a PIN protected field without prior correct PIN reception in the current 
call; or 

'content not accepted' error case for a malformed field; or 

'procedure not allowed' error case for a non-editable field, for an unknown field id (e.g. not implemented 
by the FP), or for a field not requested in the previous 'edit entry' command 

NOTE 1 : Non-editable fields should not be present in the save command, as the PP is not supposed to modify their 
value. See also 'Field instance management' in clause 7.4.10.1. 

• Sending a negative acknowledgement ('PIN code required', 'content not accepted', 'procedure not allowed') at 
the end of the command if applicable, even if the command was partially carried out. 
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NOTE 2: The steps described above for field (instance) modification apply also for: 

■ field resetting of an editable single instance PIN protected field (this is a kind of field 
modification); 

■ field instance deletion or addition of a multiple instance PIN protected field. 

NOTE 3: This means that when an error is encountered, all subsequent fields in the command will still be processed 
by the FP even if the sending of a negative acknowledgement is planned for the command. 

• If several error codes apply, the FP shall send one of them. 

NOTE 4: Owing to the previous requirements, the FP might send a 'PIN code required' negative acknowledgement 
even when an unchanged PIN protected field is included in the 'save entry' command (i.e. if the correct 
PIN was not received before). The PP may avoid this drawback by saving only modified PIN protected 
fields or e.g. by systematically asking the user for the PIN in the session if the list contains PIN protected 
fields). 

NOTE 5: The "best effort" mode aims at handling several error situations. However in most cases, the FP will 
successfully save all fields included in the 'save entry' command. 



Table 52: Values used within {IWU-INFO} message for "Save entry" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminated 


03H 


List access 


<Command = save entry> 


AH 


List access command 


<Session identifier 


1..127 


Session identifier (see note) 


<Entry identifier 


0..127 


Entry identifier (see note) 


NOTE: 'Session identifier' and 'entry identifier' can be extended for values up to 16 383 by using the same 
mechanism as for 'Event multiplicity'. See note 1 at table 39. 



Content of list entry is transmitted in data packets. 
Entry identifier: 

Bits 7 6 5 4 3 21 Meaning 

not yet assigned entry identifier (new entry proposed by the PP) 

other values assigned entry identifier (this entry identifier shall already exist in the list) 

New entry creation: 

If a new entry has to be created, the PP shall indicate this by using the entry identifier 00H. In this case, the end FP shall 
assign a new entry identifier for the entry and submit it in the following 'save entry confirm'. 

For more information, see clause 7.4.10.1, 'Field instances management' entry. 

The FP entry identifier assignment method is left free to implementation. However, the FP should not re-assign a 
previously freed (e.g. because of deletion of an entry) entry identifier before all sessions which were accessing this list 
at the time of freeing the entry identifier have been closed. By this way, possible inconsistencies in other PPs which 
have active sessions to the same list are avoided. 

The FP may implement the " re-use if possible method " described below. 

The "re-use if possible method" consists in assigning an entry identifier to a new entry in the interval [1, n] for a given 
list: 

• Assignment starts or restarts at 1 when list is empty. 

• For further entries, if only 1 session is opened on the list, the rule "Assigned id = smallest free id" applies. Free 
id may correspond to a never used or previously freed entry id. 
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• For further entries, if more than one session is opened on the list, the rule "Assigned id = smallest free id" 
applies, with the additional requirement that the assigned id shall have remained free (i.e. shall not have been 
used and then deleted) since the list was in idle the last time. 

• This method assumes that n is never reached, n is larger than maximum number of entries in the list. 
New or modified entry insertion in the list: 

The new or modified entry shall be inserted in the list by the FP taking into account the sorting criteria for this list. 
Edit command without modification: 

If the previously started edit procedure has to be terminated without changing the list entry, PP shall perform the 'save 
entry' procedure with only one empty 'last data packet' following the 'save entry' (an example is provided in 
clause C.5.9). 

Field instance reset, emptying or deletion with a save entry command: 

A PP may request the reset, emptying or deletion of a field instance by using an empty field instance in a "save entry" 
command (length of the field instance set to 1). Table 52a lists the different cases. 

Field reset allows to reset the field in the FP and come back to its default value (defined in the present document or 
manufacturer defined). When resetting a field instance, the FP shall replace it in the list entry with the (non-empty) 
default value defined for that field. 

NOTE 6: It has to be noted that for some fields in some lists, resetting can be dangerous and should be carefully 
controlled by the PP. 

Field emptying allows to set an empty value for the field. Applies only to a limited number of fields in the present 
document. 

Field deletion allows to delete one instance of a multiple instance field in the FP. When deleting a field instance, 
the FP shall respect the order of the remaining instances (as stated in clause 7.4.10.1, "Field instances 
management"). The deleted instance is removed from the list entry, not replaced with the received empty instance. 

NOTE 7: Empty field instances are defined in clause 7.4.10.5.1. 



Table 52a: FP behaviour when "length=1" in a save entry 



Field name 
(note 1) 


FP behaviour 


Comment 


Fields which may be reset individually by the PP 


Contact List: 
- Line id 


FP shall reset the field to the 
default value (if editable) 


The FP uses the FP defined default value for a contact. 
For example, it could be the "All lines" value. 
See also note 2. 


Internal Names List: 

- Name (of handset) 

- Call interception 


FP shall reset the field to the 
default value (if editable) 


The FP uses the FP defined default value. 
See also note 2. 


DECT System Settings 
List: 

- Clock master 

- Base reset 

- Emission mode 

- New PIN code 


FP shall reset the field to the 
default value (if editable) 


The FP uses the FP defined default value. 

For "base reset", default value is "YES" by standard; this 

is therefore equivalent to setting the value to "YES" 

directly (with all consequences defined in 

clause 7.4.1 1.3.3). 

See also note 2. 


Line Settings List: 

- Line name 

- Attached handsets 

- FP volume 

- Multiple calls mode 

- Intrusion call 

- Permanent CLIR 

- Call forwarding (CFU, 
CFNA and CFB) 


FP shall reset the field to the 
default value (if editable) 


The FP uses the FP defined default value. 
See also note 2. 
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Field name 
(note 1) 


FP behaviour 


Comment 


Fields which may be reset individually by the PP 


Name 

First name 

Dialling prefix 

FP IP address / value 

FP IP address / subnet 
mask 

FP IP address / gateway 
Associated melody 
FP melody 


FP shall set the field to empty 
value (length=1) 


Empty value is selected because it is an allowed value for 
the field. Deletion is not applicable to those single 
instance fields. 

See also note 3. 


Fields which are always empty 


Read status 

FP IP address /type 


FP shall update the property 
octet with received bits sent by 
the PP (if field is editable) 


Save entry command can only be used with length=1 on 
those fields. 

Deletion is not applicable to those single instance fields. 


Contact number 

Blocked number 

FP IP address / DNS 
server 


FP shall remove field instance (if 
editable) 

However, if all field instances of 
a given field are present in the 
save entry command, and have 
length=1 , all but one instances 
shall be removed in the FP; for 
the remaining one, the empty 
value shall be used (note 4) 


The PP may delete all but one instances. 

See clause7.4.10.1, "Field instance management", for more 

details 


NOTE 1 : Fields that are always uneditable (see annex H) are not listed here. For such fields, the FP answers 

"procedure not allowed". Always uneditable fields include: Call type, Date and time, FP version (all subfields), 
Line name (in a call list), Line id, Number, Number of calls. This also includes the "Current PIN code" which is 
not modifiable (for this field, the FP answers "incorrect PIN"). 

NOTE 2: For those fields, an empty value is not allowed in the list entry (as stated in the field definition). As a result, 
"length = 1" can be used in the save entry command for the purpose of resetting the field. 

NOTE 3: Individual field resetting using length=1 is NOT possible here because use of an empty-value field (i.e. with 
length = 1) in the list entry is allowed. In addition, the PP cannot reset the field directly as it happens that no 
reset value for this field is defined in the present document. Although not possible for the field individually, a 
reset value defined by the FP can still be restored through a global reset (base reset). 

NOTE 4: This implies that the PP requested all available instances of the field in the previous edit entry command. 



Possible error cases: 

NOTE 8: Where several error cases apply (e.g. for different fields) a negative acknowledgement will be sent; 
however, the used 'reject reason' may be different from the one indicated below. 

NOTE 9: As described in clause 7.4.10.4.9, the negative acknowledgement is sent after the 'data packet last' 
information is received from the PP. 

Invalid session number: If session identifier is wrong the FP shall answer with negative acknowledgement reject 
reason 'invalid session number'. 

Entry not available: If an unknown entry identifier of the list is requested (except 0), the FP shall answer with negative 
acknowledgement, reject reason 'entry not available'. 

Entry format incorrect: If a PP attempts to save an entry with an incorrect format, the FP shall reject the command with 
a negative acknowledgement, with reject reason "Entry format incorrect". 

Content not accepted: If a PP attempts to save an entry with correct format but with a field content which cannot be 
accepted, (e.g. for a field whose contents are only allowed once in the list like line-id in the Line Settings List or when 
too many instances of a field are saved in the same entry), the FP shall reject the command with a negative 
acknowledgement, with reject reason "content not accepted". 
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List full: If a PP attempts to add a new entry in a list which cannot accept an additional entry, the FP shall reject the 
command with a negative acknowledgement, with reject reason "list full". 

PIN code required: If a PP attempts to perform an operation subject to prior correct PIN entry (e.g. PIN protected field 
modification, etc. See clause 7.4.1 1.1, entry 'PIN code' for details), the FP shall send a negative acknowledgement, with 
reject reason 'PIN code required'. 

NOTE 10: As described at the beginning of the present clause and in clause 7.4.10.4.9, error codes 'content not 

accepted' and 'PIN code required' can be sent even if the 'save entry' command was partially carried out. 

Procedure not allowed: The FP shall reject the save entry command with a negative acknowledgement with reject 
reason 'procedure not allowed' in the following cases: 

• the PP inserts a non-editable field (whether actually modified or not); 

• the PP inserts an entry (identifier) that was not previously requested in a previous edit entry command; 

• one of the fields inserted by the PP has an unknown identifier 

EXAMPLE: An optional field on FP side that is not implemented by the FP is a kind of field with unknown 
identifier. 

NOTE 10a: However, a PP should use the 'Query supported entry fields' command (see clause 7.4.10.4.2) in order 
to avoid sending unimplemented fields to the FP. 

The FP may reject the save entry command with a negative acknowledgement with reject reason 'procedure not allowed' 
in the following cases: 

• the FP does not allow the saving of new entries for a given list (e.g. for call lists, for the Line Settings List). 

NOTE ll:For lists that allow creation of a new entry initiated by the PP, it is supposed that all fields are editable on 
FP side. 

7.4.1 0.4.5.2 "Save entry confirm" command 

This command from FP confirms the save of one entry in a list and returns the position index where the entry was 
saved. 



Table 53: Values used within {IWU-INFO} message for "Save entry confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminated 


03H 


List access 


<Command = save entry confirm> 


BH 


List access command 


<Session identifier 


1..127 


Session identifier (see note) 


<Entry identifier 


1..127 


Entry identifier (see note) 


<Position index> 


1..127 


Position index (see note) 




<Total number of available 
entries> 


0..127 


Number of available entries in list 
after saving (see note) 


NOTE: 'Session identifier', 'position index', 'entry identifier', and 'total number of available entries' can be 

extended for values up to 16 383 by using the same mechanism as for 'Event multiplicity'. See note 1 at 
table 39. 



The position index indicates the (possibly new) index of the entry in the list. 

The 'Total number of available entries' reflects the updated number of entries in the list after save is performed. It is 
useful especially when saving (creating) a new entry. 
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7.4.10.4.6 Delete entry 

7.4.1 0.4.6.1 "Delete entry" command 

This command from PP requests to delete one entry in a list. 



Table 54: Values used within {IWU-INFO} message for "Delete entry" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminated 


03H 


List access 


<Command =delete entry> 


CH 


List access command 


<Session identifier 


1..127 


Session identifier (see note) 


<Entry identifier 


1..127 


Entry identifier (see note) 


NOTE: 'Session identifier' and 'entry identifier' can be extended for values up to 16 383 by using the same 
mechanism as for 'Event multiplicity'. See note 1 at table 39. 



The 'delete entry' command is not allowed for the following lists: 

• List of Supported Lists; and 

• DECT System Settings List. 

The 'delete entry' command for the Internal Names List shall respect the following rules: 

• it shall be interpreted as a request for de-registering from the system the PP listed in the entry to be deleted 
(see clause 7.4.1 1.2); 

• if this PP is involved in a call, the FP shall reject the 'delete entry' command by sending a negative 
acknowledgement with reject reason, 'temporarily not possible' (as defined in clause 7.4.10.6). 

The FP may forbid the use of the 'delete entry' command for the Line Settings List'. See 'possible error cases' below for 
the appropriate answer. 

Possible error cases: 

Invalid session number: If session identifier is wrong the FP shall answer with negative acknowledgement reject 
reason 'invalid session number'. 

Entry not available: If an unknown entry identifier of the list is requested, the FP shall answer with negative 
acknowledgement with reject reason 'entry not available'. 

Procedure not allowed: If the PP sends a 'delete entry' command in a case where it is not allowed (see above), the FP 
shall answer with negative acknowledgement with reject reason, 'procedure not allowed'. 

PIN code required: If a PP attempts to delete an entry with PIN protected fields without previously sending the correct 
PIN, the FP shall send a negative acknowledgement, with reject reason 'PIN code required' (see clause 7.4. 1 1 . 1 , 
subsection 'PIN code'). 

7.4.1 0.4.6.2 "Delete entry confirm" command 

This command from FP confirms the deletion of an entry in a list. 
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Table 55: Values used within {IWU-INFO} message for "Delete entry confirm" command 



Information element 


Field within the information 
plpmpnt 

1 III III 


Standard values 
within thp fipld/IE 

Will III 1 HI W 1 Ivlv' 1 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command = delete entry 
confirm> 


DH 


List access command 


<Session identifier 


1..127 


Session identifier (see note) 


<Total number of available 
entries> 


0..127 


Number of available entries in list 
after deletion (see note) 


NOTE: 'Total number of available entries' and 'session identifier' can be extended for values up to 16 383 by 
using the same mechanism as for 'Event multiplicity'. See note 1 at table 39. 



7.4.10.4.7 Delete list 

7.4.1 0.4.7.1 "Delete list" command 

This command from PP requests the deletion of a complete list. 

Table 56: Values used within {IWU-INFO} message for "Delete list" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminated 


03H 


List access 


<Command =delete list> 


EH 


List access command 


<Session identifier 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended for values up to 16 383 by using the same mechanism as for 'Event 
multiplicity'. See note 1 at table 39. 



Delete list means deletion of all entries. The list itself is still available. 

Use of the 'Delete list' command is not allowed for the following lists (see also 'possible error cases' below): 

• List of Supported Lists; 

• Internal Names List; 

• DECT System Settings List; and 

• Line Settings List. 
Possible error cases: 

Invalid session number: If session identifier is wrong the FP shall answer with negative acknowledgement reject 
reason 'invalid session number'. 

Procedure not allowed: If an unknown list identifier is requested (including the List of Supported Lists), the FP shall 
answer with negative acknowledgement, reject reason 'procedure not allowed'. 

Procedure not allowed: If the FP rejects the 'delete list' command, it shall answer with a negative acknowledgement, 
with reject reason = 'procedure not allowed'. This negative acknowledgement shall be used in particular if the 'delete 
list' command is used for one of the lists for which this command is not allowed (see above). 

7.4.1 0.4.7.2 "Delete list confirm" command 

This command from FP confirms the deletion of a complete list. 
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Table 57: Values used within {IWU-INFO} message for "Delete list confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminated 


03H 


List access 


<Command =delete list confirm> 


FH 


List access command 


<Session identifier 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended for values up to 16 383 by using the same mechanism as for 'Event 
multiplicity'. See note 1 at table 39. 



7.4.10.4.8 Search entries 

7.4.10.4.8.1 "Search entries" command 

This command from PP requests to read a range of consecutive entries in the list, beginning with an entry matching a 
search criterion. The list here shall be understood as the list resulting from the initial sorting of the list as specified by 
the FP in the "Start session confirm" command. 

When the list is sorted using an alphanumerical field, the sorting of the list is case insensitive, as indicated in 

clause 7.4.10.4.1.1. Consequently the search performed by the 'Search entries' command shall also be case insensitive in 

that case, and the 'search criterion' used shall also be considered case insensitive. 

NOTE 1: This command should be considered as an enhanced 'read entries' command, intended to display on PP 

side a chosen number of consecutive entries, starting (or ending) with a specific entry in the list. Only this 
specific entry is the target of the search mechanism. Other returned entries just follow (or precede) the 
specific entry in the sorting order used for the list. 

NOTE 2: As a consequence, this command should not be considered as a command retrieving all entries matching 
the search criterion in the list. 

For the 'Search entries' command, the requested subset of fields should not be empty. 
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Table 58: Values used within {IWU-INFO} message for "Search entries" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command = search entries> 


10H 


List access command 


<Session identifier 


1..127 


Session identifier (see note 1) 


<Matching option> 


00H to 06H 


First part of the search criterion 


<-Ocdi ui icU Valued 




QopnnH nort rtf tho coar^h rritorinir 
OcLUI IU \Ja\ L U I LI Ic bcdlUI 1 1 Ltrl IUI 1 , 

Always coded as a string 


<String length> 


1..255 




<String content 0> 




UTF-8 coded characters 








<ouing content n> 




u i r-o coaea cnaraciers 


<Direction (bit 8)> 
<Counter (bits 1 to 7)» 


n 1 
U..1 

1 ..127 


Direction of the read (forward or 
backward) 

Number of requested entries 


<Mark entries request> 


00H, 7FH, FFH 


Flag for requesting resetting (or 
setting) of the 'Read status' field for 
all read entries (see note 2) 


<List entry field identifier 1> 


0..255 


Requested field element type 








<List entry field identifier n> 


0..255 


Requested field element type 


NOTE 1 : 'Session identifier' can be extended for values up to 16 383 by using the same mechanism as for 'Event 

multiplicity'. See note 1 at table 39. 
NOTE 2: This field is only considered if the list contains a 'Read status' field. Otherwise it is present but ignored on 

both sides (see also clause 7.4.10.4.3, 'Read entries'). 
NOTE 3: 'List entry field identifier' values are defined for each list separately. 



In the list access command 'search entries', the submitted searched value contents together with the matching option 
define the search criterion. 



FP answers with list entries beginning with the first matching entry, but it does not generate a new list for the result. A 
matching entry shall be understood with the matching option taken into account. 

The "Search entries" command shall be considered successful if at least one entry is found that matches the search 
criterion, and even if there are less than <counter> entries (including the matching entry) available in the requested 
'direction' for answering the request. See "Search entries confirm" command/particular cases for the case the search 
does not succeed (no entry found at all). 

The command 'search entries' is in principle similar to 'read entries' with the exception, that instead of 'start index' the 
'searched value' is used. 



Matching option: 

Bits 87654321 Meaning 

00000000 exact match with whole target field required 

00000001 exact match as with 00H option tried, current start index returned if exact match fails 
00000010 exact match as with 00H option tried, previous start index returned if exact match fails 
all other values reserved 



If '00'H matching option is used, the FP shall only succeed if it finds an entry in the list with first sorting field value 
equal to the searched value. If the search field is alphanumerical, equal shall mean case insensitively equal (e.g. 'La' 
shall match 'LA', La', '1A' and 'la'). When there is a failure, the command shall return a "not matching" answer (see "not 
matching case section" in clause 7.4.10.4.8.2). 

NOTE 3: This option is especially useful for the PP to retrieve a specific entry with no human intervention. 
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'01'H and '02'H options allow to search the "nearest" alphanumeric al entry/entries in the list to the searched value (for 
example, option '01'H could be convenient if user/PP only enters "s" when searching for all entries starting with "s"). 

If '01'H matching option is used, the FP shall only succeed if either the exact match succeeds (as with option 00H), or if 
the end of the list was not reached when the exact match failed. The current entry index shall be returned as start index 
of the returned range. If the end of the list was reached when the exact match failed (there is no current entry anymore), 
the FP shall return a "not matching" answer (see "not matching case section" in clause 7.4.10.4.8.2). 

If '02'H matching option is used, the FP shall only succeed if either the exact match succeeds (as with option 00H), or if 
the current entry when the exact match failed was not the first entry of the list. The "previous index" = "current entry 
index -1" shall be returned as start index of the returned range. If the current entry when the exact match failed was the 
first entry of the list, the FP shall return a "not matching" answer (see "not matching case section" in 
clause 7.4.10.4.8.2). 

EXAMPLE 1: If "Smi" is the searched value, with matching option '01'H, and there is no entry with "Name" field 
equal to "Smi" in the list, exact match will fail on the first entry ranked after "Smi" in the list when 
using the alphanumerical order. This entry is the so-called "current entry" and may have e.g. 
"Smith" as "Name" field value, or any other value. 

EXAMPLE 2: If "s" is the searched value, with matching option '01'H, FP will answer in search confirm with the 
index of the first entry starting with a "s". If there are none, FP will answer with index of the first 
entry starting with a "t" and so on. 

Searched value: 

The FP shall use the 'searched value' as search criterion in the entry field which was used as first criterion by the FP for 
sorting the list; this sorting field is indicated to the PP in the 'Start session confirm' command. 

The FP shall use the 'Searched value' as a case insensitive input field. 

EXAMPLE 3: The 'Search entries' command shall give the same result for a 'Search value' equal to 'Smi', 'smi', or 
'SMI'. 

If a numerical value is searched the string content fields shall contain the IA5-coded decimal representation of the value 
(e.g. when searching for Line id =12, the string content is '31'H '32'H). 

NOTE 4: This particular coding of numerical values does not imply anything about the underlying sorting order of 
the list, which depends on the sorting fields defined for the session and on their types (see "Start session" 
command). 

Direction and Counter (octet): 

See the "Read entries" command (see clause 7.4.10.4.3), as the same definition applies here. 
Mark entries request: 

See the "Read entries" command (see clause 7.4.10.4.3), as the same definition applies here. 
List entry field identifier: 

When reading entries through the 'Search entries' request, the PP specifies the requested fields by using 'list entry field 
identifiers'. For more information, see clause 7.4.10.1, 'Field instances management'. 

NOTE 5: A PP has to enumerate the field ids in the request even if it is requesting all fields. 

When several list entry field identifiers are specified within the command, these field identifiers shall be ordered in 
ascending numerical order. 

Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

If an unknown list entry field identifier is requested the FP shall ignore this field and continue with the next requested 
field. 
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7.4.1 0.4.8.2 "Search entries confirm" command 

This command from the FP specifies the start index of the range of entries found as a result of the "Search entries" 
command, and the number of returned entries. Corresponding entry/entries are sent along in data packets. 



Table 59: Values used within {IWU-INFO} message 
for "Search entries confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminated 


03H 


List access 


<Command = search entries 
confirm> 


1 1 H 


List access command 


<Session identifier 


1..127 


Session identifier (see note) 


<Start index> 


1..127 


Start index of the range of returned 
entries (see note) 


<Partial delivery (bit 8)> 
<Counter> (bits 1 to 7) 


0..1 
0..127 


Partial delivery owing to FP memory 
limitation 

Number of actually delivered entries 


NOTE: 'Session identifier' and 'start index' can be extended for values up to 16 383 by using the same 
mechanism as for 'Event multiplicity'. See note 1 at table 39. 



'Partial delivery' and 'Counter' (octet): 

The 'Counter' subfield (bits 1 to 7) contains the number of list entries that will be actually delivered in following data 
packets / data packet last. 

The 'Partial delivery' flag (bit 8) indicates (when set) that the FP can only partially carry out the request, owing to 
memory limitations (response too big). 

Bits 87654321 Meaning 

Oxxxxxxx Full delivery (bit 8 not set); Counter (bits 1 to 7) 
lxxxxxxx Partial delivery (bit 8 set); Counter (bits 1 to 7) 

For details on the use of 'bit 8', see clause 7.4.10.4.3.2. 
Start index returns the index of the first returned list entry. 
Content of list entry/entries is transmitted in data packets. 
Not matching case: 

If no entry is found that matches the search criterion, the <counter> field value shall be set to zero. No data packet shall 
be sent. 

7.4. 10.4.9 Negative Acknowledgement 

This command from the FP rejects the previous command with a reject reason, and is sent instead of the regular 
command confirmation. 

The FP shall wait until the erroneous command is completely received from the PP before replying with a negative 
acknowledgement. For commands containing data (i.e. for the save command), this implies waiting until the 'data 
packet last' information is received. 

For the 'save entry' command, a negative acknowledgement with reject reason 'content not accepted' or 'PIN code 
required' may only mean partial rejection of the command. See clause 7.4.10.5.1 for more information. 
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Table 60: Values used within {IWU-INFO} message for "Negative Acknowledgement" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminated 


03H 


List access 


<Command=negative 
acknowledgement 


12H 


List access command 


<Session identifier 


1..127 


Session identifier (see note) 


<Reject reason> 


0..255 


Reject Reason 


NOTE: 'Session identifier' can be extended for values up to 16 383 by using the same mechanism as for 'Event 
multiplicity'. See note 1 at table 39. 



Reject reason: 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 















































1 




















1 























1 


1 

















1 























1 





1 

















1 


1 




















1 


1 


1 














1 























1 








1 














1 





1 

















1 





1 


1 



all other values 



Meaning 

invalid range 
entry not available 
invalid session number 
temporarily not possible 
entry format incorrect 
invalid start index 
procedure not supported 
procedure not allowed 
content not accepted 
list full 
incorrect PIN 
PIN code required 



In the case of 'invalid session number', the invalid session identifier of the acknowledged command is used in the 
negative acknowledgement. 

7.4. 10.4.10 Data packet / Data packet last 

These packets allow to send data content along with a command. 



Table 61 : Values used within {IWU-INFO} message for "Data packet" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 




<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command =data packet / data 
packet last> 


13H/14H 


List access command 


<Session identifier 


1..127 


Session identifier (see note) 


<Data content byte 0> 


0.. 255 


Content first byte 








<Data content byte n> 


0.. 255 


Content last byte 


NOTE: 'Session identifier' can be extended for values up to 16 383 by using the same mechanism as for 'Event 
multiplicity'. See note 1 at table 39. 



'Data packet last' is used if no more data will be sent for this response. 
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Data content is structured as follows. 



Table 62: Data content structure in the "Data packet" command 



Information element 


rieiu wiimn ine inTurmduun 

ClCl 1 ICI 11 


oLdllUdiU Values 
u/ithin tho fiolH/IF 

VVIllllll lilt; llCIU/lt. 


iNurrridii vc aciiun/ournrneni 


«IWU to IWU» 


<Entry id© ntif i© r for 1 s * Gntry> 




lUtMIUMtJI Ul 11 ic ciiiiy pec IIULoo 1 

and 2) 


•tf'Fntrv lpnnth"> 

i — liny itfiiyiii^* 


0..127 


1 pnnth tepp nntp 1\ 

1 — V-/ 1 lyl-l 1 1 1 IU 1 1 


<rFntrv fipld idpntifipr 1 ^> 

l_ I 1 L 1 y II w 1 \-A 1 \A vl 1 L 1 1 lul 1 --- 


0.. 255 




^Fntrv fipld lpnnth"> 

l_ 1 1 L 1 V II w IU 1 \j 1 1 \-j L 1 1 .-- 


0..127 


1 pnnth fcipp nntp 1^ 

1 — V-/ 1 ly LI 1 ICUU 1 IULU 1 1 


•^Fntrv fipld rnntpnt 0~> 

^ 1— — 1 1 L 1 y II 1 \Ji \s\J 1 1 L v_/ 1 11 U -"^ 












•^Fntrv fipld rnntpnt v> 

^ 1 — IILly 1 \ \j IVJ OUl 1 1 L 1 






<rFntrv fipld idpntifipr 

1_ 1 1 L 1 y II \j 1 \Jl 1 \A v 1 1 L 1 1 1 *j 1 l_ --- 


0.. 255 










<Entry field identifier n> 


0..255 




<Entry field length> 


0..127 


Length (see note 1 ) 


<Entry field content 0> 












<Entry field content j> 






<Entry identifier for 2™ entry> 


1..127 


Identifier of the entry (see note 1) 


<Entry length> 


0..127 


Length (see note 1 ) 








Continues with further entries 






NOTE 1 : 'Entry identifier', 'entry length', and 'entry field length' can be extended for values up to 16 383 by using 

the same mechanism as for 'Event multiplicity'. See note 1 at table 39. 
NOTE 2: 'Entry identifier' value is used only when performing a 'save entry' command to save a new entry. 



The data content is distributed over several 'data packet' messages. One entry field might be distributed over more than 
one data packet. 

When several entry field identifiers are specified within the data packet command, these field identifiers shall be 
ordered in ascending numerical order. 

NOTE: This is valid for example in the 'read entries confirm', 'edit entry confirm', 'save entry' and 'search entries 
confirm' related data packets commands. 

The maximum information length of a LAPC UI frame is 63 octets (see EN 300 175-4 [4]). As a consequence, each 
"Data packet" and "Data Packet last" commands can carry up to 56 octets in data content, as the header of "Data packet" 
message is 7 octets length. 

Table 63: Header message structure of "Data packet" command 





Octet: 


Transaction Identifier Protocol Discriminator 


1 


Message Type = {IWU-INFO} 


2 


Information element = «IWU to IWU» 


3 


Length of contents; L (octets) 


4 


Protocol Discriminator = List Access 


5 


Command = data packet 


6 


Session identifier 


7 



If the data content exceeds the 56 octet limit, the data content shall be segmented into two or more data packets and 
these data packets shall be transmitted consecutively. 
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Data packet (session id i) 



id 1 



igi 



Content 1 



IWU-lnfo «IWU to IWU» IWU-lnfo «IWU to IWU» 



IWU-lnfo «IWU to IWU» 



Data packet (session id i) 



Data packet last (session id i) 



End content 1 


id2 


ig 2 


Content 2 


id3 


ig 3 


Content 3 



Ig 1 bytes 



Entry 1 



Ig2 bytes 



Entry 2 





Entry field 1 




Entry field 2 






Entry field i 


Eid1 


Lgf1 


Fcontentl 


Eid2 


Lgf2 


Fcontent2 




Eid i 


Lgfi 


Fcontenti 



Figure 55: Example of one entry distributed over two data packets 

The following notations are used in the figure 55 above: 

• idl, id2, id3: entry identifier for entry 1, entry 2 and entry 3. 

• lgl, lg2, lg3: entry length for entry 1, entry 2 and entry 3. 

• Content 1, Content 2, Content3: entry content for entry 1, entry 2 and entry 3. 

• Eidl, Eid2, Eid3: field identifier for field 1, field 2 and field 3 of entry 1. 

• Lgfl, Lgf2, Lgfi: field length for field 1, field 2, ... .field I of entry 1. 

• Fcontentl, Fcontent2, Fcontenti: field content of field 1, field content of field 2, . . .field content of field I of 
entry 1. 

For entry field contents see clause 7.4.10.5.1. 
When sending consecutive segmented data packets: 

• PP and FP shall support any {IWU-INFO} message length sent by the remote side, up to the limit of 63 bytes 
as defined in the NWK standard. 

• However, when sending data packets, the FP should fill the payload of «IWU-Info» messages in a way to 
optimize the bandwidth used on the C s Channel. 

7.4.1 0.5 Lists and entry fields 

In the following, the entry field identifiers for various lists are defined. 

Proprietary list fields shall have entry field identifiers with the most significant bit set to 1'. 
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7.4.10.5.1 Fields description 

For the fields described in the following clauses: 
Field identifier octet: 

This field value depends on the list the field is used in, and is indicated for each list in the list definition. 
Length octet and related extension bit: 

The extension bit of the length octet of a field shall be set to 1 if the length is inferior to 128. If the length is equal or 
superior to 128, more than one byte is used for the field length, the highbyte shall be send before the lowbyte (e.g. T is 
coded as 81H, '128' is coded as 01H 80H). 

The length value (bits 1 to 7 if extension bit is set) shall be the set to the number of octets in the field starting 
immediately after the last length octet. In particular, it shall include the properties octet defined below. 

Empty field (instance): 

An empty field instance is defined as a field instance with no value, that is, as a field instance with a length set to 1' 
(accounting for the 'properties' octet). 

NOTE 1 : The 'value' of the field is defined here as the set of all octets of the field from octet 4 on. This should not 
be confused with the 'Value' subfield included in some field definitions. 

NOTE 2: Use of an empty field instance in a "save entry" command for field instance deletion or resetting is 
described in clause 7.4.10.4.5.1. 

Properties octet and related extension bit: 

The extension bit shall be used to extend the 'properties octet' from 1 to several octets if needed (usual DECT extension 
bit mechanism). This bit shall be set to 1 if the property bits are coded on 1 octet. 

For some fields, an "editable" property bit exists. The "editable" property bit is set to "1" by the FP to indicate to the PP 
if the field of this entry can be further modified by the PP during a save command. If so, the PP may modify the value 
(octet 4 and more) and/or the property bits (octet 3) of the field in a further save command. 

The "editable" bit itself cannot be modified by the PP (even if set to 1'). Any modification of this bit shall be 
disregarded by the FP. When creating a new entry (with a save command from PP to FP), the PP may set the "editable" 
property to any value ('0' or T). The FP will ignore this value and set it to the desirable value. 

NOTE 3: The "editable" bit should be set to '1' by the FP only when strictly necessary. For example call related lists 
entry fields should not be editable. Contact List entry fields should be editable. 

The "editable" property bit does not restrict the set of fields that can be requested in the 'edit' command itself, which is 
provided for editing an entry as a whole. Any field (editable or not) can be included in an 'edit entry' command. 

PP requirement: The PP should prevent edition of non-editable fields (i.e. with "editable" property reset), to avoid 
misleading the user, and shall not insert a non-editable field in the following save entry command (see 
clause 7.4.10.4.5). 

NOTE 4: For some fields, the "editable" property is liable to change over the lifetime of the FP (see "FP 
requirements" below and annex H); the PP should be carefully implemented in order to take this 
flexibility into account. 

FP requirement: Annex H summarizes for each field, if it shall be editable, if it shall not be editable, or if the editable 
field value is left free to the implementer. In the latter case: 

• the "editable" field value may vary with time (or not) within the lifetime of the FP; 

• the "editable" field value may even vary from entry to entry for the same field (see annex H, Contact List 
case). 

The "PIN protected" property bit allows the FP to protect the field against unauthorised modification by mandating PIN 
code entering before performing a save command on the field. See clause 7.4.1 1.1 for details. 
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The "PIN protected" property bit itself cannot be modified by the PP (even if set to T). Any modification of this bit 
shall be disregarded by the FP. When creating a new entry (with a save command from PP to FP), the PP may set the 
"PIN protected" property to any value ('0' or T). The FP will ignore this value and set it to the desirable value. 

NOTE 5: Only editable fields (with "editable" property set to 1) may need to be 'PIN protected'. 

Other property bits shall be set correctly by the PP when using the 'save' command. 

Error cases are described for each command in dedicated clauses (see clause 7.4.10.4). 



7.4.10.5.1.1 



Field 'List identifiers' 



Bits 



0/1 



0/1 



Field identifier = List identifiers 



Length (L) 



1 st supported list identifier 



^supported list identifier 



Octet 
1 
2 
3 
4 
5 



For octet 3 'x' indicates, the value is reserved for future use. 
The list identifiers shall be ordered in ascending numerical order. 
The list identifiers are defined in clause 7.4.10.3. 



7.4.10.5.1.2 



Bits 



Field 'Number' 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = Number 


1 


0/1 


Length (L 


) 


2 


0/1 


editable 


internal 


own 


X 


X 


X 


PIN 

protected 


3 


1 st digit 


4 


2™ digit 









Each digit shall be out of 30H. . .39H, 23H, 2AH, 05H, 15H. 

For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 



Length: In the call lists, for incoming accepted calls, if the number information is not provided by the network to the 
FP (e.g. no CLIP or restricted CLIP received), the FP shall set the length to 1. 

'Internal' property: The Internal' property is used to identify internal phone numbers. It shall be set to 1 when the 
Number represents a Terminal identity number (see clause 7.4.10.5.1.2.1). It shall be set to 1 in all entries of the Internal 
Names List. 

NOTE 1 : As the call related lists do not include internal calls, this property is only set for the Internal Names List 
(see clause 7.4.10.5.8). 

'Own' property: The 'Own' property is used to indicate its own entry to the PP which consults the Internal Names List. 
The FP shall set the 'Own' property to T for the PP's own entry, and to '0' for all other entries in that list. It is not used 
in other lists (set to in other lists). 

The PP should prevent the user from using the entry with 'Own' property set to T in the Internal Names List for placing 
a call, so that the user will not attempt an internal call towards its own PP. 

If a call is nevertheless attempted by a PP towards itself, the FP shall release the call properly. 

NOTE 2: The Contact List does not use the 'Number' field, but the specific 'Contact number' field (see 
clause 7.4.10.5.1.11). 
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NOTE 3: 'Editable' property is set to "0" by the FP when the field is used in the Internal Names List. 
'PIN protected' property: The 'PIN protected' property shall be set to '0', unless the field 'Number' is used: 

• as 'Dialling Prefix' field in the Line Settings List (see clause 7.4.1 1.4.4); 

• as 'Blocked number' field in the Line Settings List (see clause 7.4.1 1.4.7); 

• or as 'Terminal id number' field in the Internal Names List (see clauses 7.4.10.5.8 and 7.4.10.5.1.2.1). 

in which cases, this property can be set to '0' or T by the FP depending on its security policy on those lists. See 
clause 7.4.11.1, 'PIN code' subsection, for more information. 



7.4.10.5.1.2.1 



Field 'number' for terminal identity numbers 



This field is also used for terminal identity numbers, if needed. In that case, the digits shall correspond to the decimal 
representation of the terminal identity numbers coded in IA5. For example: 

• For terminal 1, terminal identity number is 0000 0001B, coded value is 31H. 

• For terminal 14, terminal identity number is 0000 1 1 10B, coded value is 3 1H 34H. 



7.4.10.5.1.3 



Bits 



Field 'Name' 



Field identifier = Name 



0/1 



0/1 



editable 



Length (L) 



1 st character byte 



2 character byte 



Octet 
1 
2 
3 
4 



Characters shall be coded as defined for UTF-8. 

Length: In the call lists, if the name information is not available, the FP shall set the length to 1 . This can happen if the 
call is an incoming call with no CNIP or restricted CNIP from the network. This requirement does not apply if a 
Contact List entry matching is used (name of the Contact List entry used instead, see notes 1 and 2). 

NOTE 1: It is recommended to use the "Name" field (and optionally the "First name" field) of the Contact List (if 
available) to fill in the "Name" field of call lists. For incoming calls lists (missed and accepted), it is also 
recommended to do so instead of using the CNIP provided by the network. 

NOTE 2: If the "Name" and/or "First name" fields of a Contact List entry are updated, the "Name" field of the 

relevant entries in call lists should be updated accordingly. However, when deleting the relevant Contact 
List entry, the "Name" field of the call list entry should not lose its current value. 

For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 



7.4.10.5.1.4 



Bits 



Field 'Date and time' 



8 


7|6|5|4|3|2|1 


Octet 


Field identifier = Date and time 


1 


0/1 


Length (L) 


2 


0/1 


editable | x | x | x | x ( x i, x 


3 


Content as specified for IE «Time-DATE» octet 3 


4 


Content as specified for IE «Time-DATE» octet 4 


5 







For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 
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Octets 4 and following are coded as specified for octets 3 and following in IE «Time-Date» (EN 300 175-5 [5]). 
Only 'interpretation' subfield value '000000'B (=current time/date) is allowed. Any 'coding' is allowed (time or date or 
time and date). 

In case of multiple calls it is recommended that date and time indicate the last call values. 



7.4.10.5.1.5 



Field 'Read status' 



Bits 



8 


7 6 5 4 3 


2 


1 


Field identifier = Read status 


0/1 


Length (L) 


0/1 


editable | unread | x i x j x 


X 


X 



Octet 
1 
2 
3 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 

Bit 6 of octet 3 ('unread' bit) may take the value 'unread' (1), or 'read' (0). When a new entry is added to the list, the 
'unread' bit shall be set (to 'unread' value) by the FP. 

The reset of the bit is defined by the 'read status' command, ('Mark entries request' field of the command) see 
clause 7.4.10.4.3.1. 



7.4.10.5.1.6 Field 'Line name' 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = Line name 


1 


0/1 


Length (L 


) 


2 


0/1 


editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


1 st character byte 


4 


2™ character byte 


5 







For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 

'PIN protected' property: The 'PIN protected' property shall be set to '0', unless the field 'Line name' is used in the 
'Line settings' list (see clause 7.4.1 1.4.1), in which case, this property can be set to '0' or T by the FP depending on its 
security policy for this list. See clause 7.4.1 1.1, 'PIN code' subsection, for more information. 

Character bytes: Characters shall be coded as defined for UTF-8. In particular one character may use several character 
bytes. When the field is present, the line name value (from octet 4) shall never be empty. 



7.4.10.5.1.7 Field 'Line id' 



Bits 



8 7 ,6 5 4 3 2 1 


Field identifier = Line id 


0/1 


Length (L 


) 


0/1 


editable x x x 


x x PIN 

protected 


Identifier subtype 


0/1 


Identifier value 






1 


Identifier value 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 

'PIN protected' property: The 'PIN protected' property shall be set to '0', unless the field Line id' is used in the 'Line 
settings' list (see clause 7.4.1 1.4.2), in which case, this property can be set to '0' or '1' by the FP depending on its 
security policy for this list. See clause 7.4.1 1.1, 'PIN code' subsection, for more information. 
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The structure of the Line id field aligns to the structure of IE «CALL-INFORMATION» line identifier type (see 
EN 300 175-5 [5], clause 7.7.56). 

The field specifies one unique line (alternatively "All lines"). 
Identifier subtype: 

• For all call related lists, the subtype shall be set to "Line identifier for external call" (call is external). 

• For the Contact List, subtype shall be set to "Relating to" or "All lines", depending on the contact. 

• For the Line Settings List, and for any other list, the subtype shall be set to "Relating to". 
Identifier value: 

• Examples of codings for octets 4 and 5: 

EXAMPLE 1 : line-id=2 for external call is coded as follows: '00'H, '82'H. 
EXAMPLE 2: Relating-to line-id=2 is coded as follows: '03'H, '82'H. 

EXAMPLE 3: "all lines" is coded as follows: '04'H. No identifier value in this case (no octet 5). 

• Additionally, for all call related lists, 'None' value shall not be used, the actual line identifier value chosen by 
the FP for that call shall be used instead. 



7.4.10.5.1.8 



Bits 



Field 'Number of calls' 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 






Field identifier = 


Number of calls 






1 


0/1 


Length (L) 


2 


0/1 


editable 


X 


X 


X 


X 


X 


X 


3 


value 


4 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 

Value shall be in the interval of to 255. 



7.4.10.5.1.9 



Field 'Call type' 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = Call type 


1 


0/1 


Length (L 


) 


2 


0/1 


editable 


Missed 
call 


Accepted 
call 


Outgoing 
call 


X 


X 


X 


3 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 



7.4.10.5.1.10 



Field 'First name' 



Bits 



Field identifier = First name 



0/1 



0/1 



Length (L) 



editable 



1 st character byte 



2 character byte 



Octet 
1 
2 
3 
4 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 
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Characters shall be coded as defined for UTF-8. 



7.4.10.5.1.11 



Field 'Contact number' 



Bits 



Field identifier = Contact number 



0/1 



0/1 



Length (L) 



editable 



own 



Fixed mobile work 



1 st digit 



2^digit 



Octet 
1 
2 
3 
4 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 

The 'Contact number' field is a multiple-instance field (see clause 7.4.10.1, Field instances management' paragraph) and 
therefore may be contained several times in one entry. 

A digit is out of 30H...39H, 23H, 2 AH, 05H, 15H. 

NOTE: The 'own' property is used to identify in the Contact List, contact numbers belonging to the user of the 
system. This can be extended to mobile or work numbers thanks to corresponding properties. Several 
entries in the list may have "own" property set to 1 (for example in the case of several mobile numbers, 
multiple lines systems). 



7.4.10.5.1.12 Field 'Associated melody' 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = Associated melody 


1 


0/1 


Length (L 


) 


2 


0/1 


editable 


X 


X 


X 


X 


X 


PIN 


3 
















protected 




Value 


4 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In the case of 'x', the value is 
reserved for future use. 

'PIN protected' property: The 'PIN protected' property shall be set to '0', unless the field Associated melody' is used 
as FP melody' in the 'Line settings' list (see clause 7.4.1 1.4.5), in which case, this property can be set to '0' or '1' by the 
FP depending on its security policy. See clause 7.4.1 1.1, PIN code' paragraph, for more information. 

'Value': Value shall be in the interval of 1-7. The '01'H value stands for 'melody 1', '02'H stands for 'melody 2', and so 
on. Default melody is 'melody 1' 

'Length (L)': The length of the field shall be set to '1' when the value of the field is not defined (default melody used). 
For the mapping of the melody with signal value coding, see clause 7.4.10.5.7. 

7.4.10.5.1.13 Field 'Call interception' 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 






Field identifier = 


call interception 






1 


0/1 


Length (L 


) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


Value 


4 



'PIN protected' property. The PIN protected' property shall be set to '0', unless the field 'Call interception' is used in 
the Internal Names List (see clause 7.4.10.5.8), in which case, this property can be set to '0' or '1' by the FP depending 
on its security policy for this list. See clause 7.4. 11.1, PIN code' subsection, for more information. 

'Value': Value shall be 30H or 31H. 30H stands for call interception not allowed, 31H for call interception allowed. 
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This field is related to the "call interception" procedure (see clause 7.4.16.2.2). When not allowed, it is forbidden for 
other PPs to intercept a call initiated by this PP. 

By default this field is set to 31 ('allowed' value). 
7.4.10.5.1.14 Proprietary fields 

Field identifiers from 81H and up to FFH are reserved for proprietary fields. Proprietary fields may be used with any list 
identifier code. This includes both, the codes defined in clause 7.4.10.3 and the proprietary list identifiers (81H to FFH). 

The format of the proprietary field shall be as follows: 



Bits 



8 


7 : 6 


5 4 3 2 1 


Octet 




Field identifier = 


Proprietary Field identifier (Ixxxxxxx) 


1 


0/1 


Length (L) 


2 


0/1 


Editable p 


1 P 1 P 1 P 1 P 1 P 


3 


1 st octet 


4 






n tn octet 





The use and meaning of bits p in octet 3 is up to the implementer. 

7.4.1 0.5.2 List of Supported Lists entry fields 

This list contains the identifiers of the lists which are supported by the FP (as some lists are optional on FP side). 



Table 64: List of Supported Lists entry fields 



Field identifier 


Field 


Length 
constraint 


Normative action/comment 


Clause 


01H 


List identifiers 


>8 


Single variable-length field with 
identifiers of all supported lists 


7.4.10.5.1.1 



The list identifiers are defined in clause 7.4.10.3. 

The List of Supported Lists refers to a list with only one entry. 

NOTE: The list identifiers are ordered in ascending numerical order (see clause 7.4.10.5.1.1). 
Field identifiers from 02H to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

7.4.10.5.3 Missed Calls List entry fields 

This list contains all the external missed calls occurring on any line of the DECT system. 



Table 65: Missed Calls List entry fields 



Field 
identifier 


Field 


Length 
constraint 


Normative action/comment 


Clause 


01H 


Number 


> 1 


Number of the calling party 


7.4.10.5.1.2 


02H 


Name 


> 1 


Name of the calling party 


7.4.10.5.1.3 


03H 


Date and Time 


>5 


Date and Time of the missed call 


7.4.10.5.1.4 


04H 


Read status 


= 1 


Indicates whether entry is shown first time 


7.4.10.5.1.5 


05H 


Line name 


> 2 


Name of line on which the call was 
received (cannot be empty) 


7.4.10.5.1.6 


06H 


Line id 


>3 


Id of line on which the call was received 


7.4.10.5.1.7 


07H 


Number of calls 


= 2 


Indicates amount of missed calls from this 
calling party 


7.4.10.5.1.8 
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'Line id' field: The FP shall implement the 'Line id' and Line name' fields in the list even if the multiple line feature 
[NG1.N14] is not implemented in the FP (systems with only 1 line). 

'Number of calls' field: Successive unsuccessful calls from the same remote party (and on the same line), that are close 
enough in time to one another, may be accounted for in a single Missed Calls List entry. In that case the 'Number of 
calls' field shall hold the number of these calls; otherwise it shall hold the value T. 

When a new missed call occurs from a party for which an entry already exists in the Missed Calls List, the FP shall 
implement one of the following three merging strategies concerning the 'number of calls' field: 

• Strategy 1: no merging of missed calls in the list. When a missed call occurs, a new entry shall be created by 
the FP with 'number of calls' field set to 1 ('ReadStatus' will be set to 'unread' as this is a new entry). 

• Strategy 2: merging of missed calls from the same party into one list entry. When a missed call occurs, the FP 
shall modify the existing entry and shall follow the following rules: 

The FP shall increment the 'number of calls' field (value greater than 1). 

The FP shall update the 'Date and Time' field, for example, with the date and time of the last arrived in 
time call from this remote party. 

The FP shall set the 'Read status' to 'unread' value. 

• Strategy 3: mix of Strategies 1 and 2 on a call by call basis. A FP may decide to implement merging of new 
entries with recent existing entries only, and no merging if the existing entry is very old. 

EXAMPLE: A FP could merge only with the most recent entry of the Missed Calls List. 

In any of these cases, The FP use the appropriate notifications to PPs as defined in clauses 7.4.10.2 (List change 
notification clause) and 7.4.1.3 (Missed call notification). 

PP shall support all three strategies. 

NOTE 1 : Merging in this context means that an already existing call entry is updated (with a new date/time) and 
that no new entry is added to the list. Hence, the total number of entries in the list before and after this 
missed call remains unchanged. 

NOTE 2: If one of the PPs was reading the Missed Calls List when the incoming call arrives the PP may have to 
restart the session to have a Missed Calls List status consistent with the reality. Especially when 
implementing the merging strategy (Strategy 2 or 3). Sorting of the list and read status could have 
changed in the FP after reading in the PP. 

Field identifiers from 08H to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

Display of fields: 

Minimum requirement: a PP implementing the present list shall display at least 'Number' or 'Name' and 'Date and Time' 
fields. 

If the 'Number' field is empty (length set to 1), e.g. no CLIP was received from the network, the PP should display an 
explicit string (e.g. 'unknown') as field value (translated in the language used by the user) instead of displaying nothing. 

If the 'Name' field is empty (length set to 1), e.g. no CNIP was received and no matching Contact List entry exists; see 
clause 7.4.10.5.1.3), the PP should display an explicit string (e.g. 'unknown') as field value (translated in the language 
used by the user) instead of displaying nothing. 

Additionally as many other fields as possible should be displayed. The way these fields are displayed is left free to PP 
implementation (for example other fields accessible only when viewing details of an entry). 
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7.4.1 0.5.4 Outgoing Calls List entry fields 

This list contains all external outgoing calls occurring on any line of the DECT system. 



Table 66: Outgoing Calls List entry fields 



Field 
identifier 


Field 


Length 
constraint 


Normative action/comment 


Clause 


01H 


Number 


> 2 
(note) 


Number of the called party 


7.4.10.5.1.2 


02H 


Name 


> 1 


Name of called party 


7.4.10.5.1.3 


03H 


Date and Time 


>5 


Date and Time of the call 


7.4.10.5.1.4 


04H 


Line name 


> 2 


Indicates name of line used for the 
call (cannot be empty) 


7.4.10.5.1.6 


05H 


Line id 


>3 


Id of line used for the call 


7.4.10.5.1.7 


NOTE: On outgoing call, the called number is known and shall be present (length > 2). 



'Number' field: The FP shall store the digits part of the called party number. However, the FP should not store digits 
dialled by the user after end to end connection has been established with called party (i.e. after "CS call connect" is sent 
to the PP). 

'Line id' field: The FP shall implement the 'Line id' and Line name' fields in the list even if the multiple line feature 
[NG1.N14] is not implemented in the FP (systems with only 1 line). 

Field identifiers from 06H to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

Entry merging strategy: When a new outgoing call is performed to an external party for which an entry already exists 
in the Outgoing Calls List with the same line id, the FP shall implement one of the following three merging strategies: 

• Strategy 1: no merging of outgoing calls in the list. When the new outgoing call occurs, a new entry shall be 
created by the FP, with a distinct "Date and Time" field. 

• Strategy 2: merging of outgoing calls to the same party (and on the same line) into one list entry. When the 
new outgoing call occurs, the FP shall replace the older entry with the new one (Date and Time update). 

• Strategy 3: mix of Strategies 1 and 2 on a call by call basis. A FP may decide to implement merging of new 
entries with recent existing entries only, and no merging if the existing entry is very old. 

EXAMPLE: A FP could decide to merge only (if applicable) with the most recent entry of the Outgoing Calls 
List. 

Display of fields: 

Minimum requirement: a PP implementing the present list shall display at least 'Number' or 'Name' and 'Date and Time' 
fields. 

If the "Name" field is empty (length set to 1) e.g. no matching Contact List entry exists; see clause 7.4.10.5.1.3, the PP 
should display an explicit string (e.g. 'unknown') as field value (translated in the language used by the user) instead of 
displaying nothing. 

Additionally as many other fields as possible should be displayed. The way these fields are displayed is left free to PP 
implementation (for example other fields accessible only when viewing details of an entry). 
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7.4.1 0.5.5 Incoming Accepted Calls List entry fields 

This list contains all the accepted external incoming calls occurring on any line of the DECT system. 



Table 67: Incoming Accepted Calls List entry fields 



Field 


Field 


Length 


Normative action/comment 


Clause 


identifier 




constraint 






01 H 


Number 


> 1 


Number of the calling party 


7.4.10.5.1.2 


02H 


Name 


> 1 


Name of calling party 


7.4.10.5.1.3 


03H 


Date and Time 


> 5 


Date and Time of the call 


7.4.10.5.1.4 


04H 


Line name 


> 2 


Name of line on which the call was 
received (cannot be empty) 


7.4.10.5.1.6 


05H 


Line id 


>3 


Id of line used for the call 


7.4.10.5.1.7 



'Line id field': The FP shall implement the 'Line id' and Line name' fields in the list even if the multiple line feature 
[NG1.N14] is not implemented in the FP (systems with only 1 line). 

Field identifiers from 06H to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

Entry merging strategy: The same approach as for the 'Outgoing call' list shall be used, except that it applies here to 
external accepted incoming calls from a given external party to a given line. Please refer to clause 7.4.10.5.4 Outgoing 
Calls List entry field, 'Entry merging strategy' entry. 

Display of fields: 

Minimum requirement: a PP implementing the present list shall display at least 'Number' or 'Name' and 'Date and Time' 
fields. 

If the 'Number' field is empty (length set to 1), e.g. no CLIP was received, the PP should display an explicit string (e.g. 
'unknown') as field value (translated in the language used by the user) instead of displaying nothing. 

If the 'Name' field is empty (length set to 1), e.g. no CNIP was received and no matching Contact List entry exists; see 
clause 7.4.10.5.1.3), the PP should display an explicit string (e.g. 'unknown') as field value (translated in the language 
used by the user) instead of displaying nothing. 

Additionally as many other fields as possible should be displayed. The way these fields are displayed is left free to PP 
implementation (for example other fields accessible only when viewing details of an entry). 

7.4.10.5.6 All Calls List entry fields 

This list contains all external calls (missed, outgoing, incoming accepted) occurring on any line of the DECT system. 



Table 68: All Calls List entry fields 



Field 


Field 


Length 


Normative action/comment 


Clause 


identifier 




constraint 






01H 


Call type 


= 1 


Coding of the list: 

missed / accepted / outgoing 


7.4.10.5.1.9 


02H 


Number 


> 1 
(note) 


Number of the calling/called party 


7.4.10.5.1.2 


03H 


Name 


> 1 


Name of calling/called party 


7.4.10.5.1.3 j 


04H 


Date and Time 


>5 


Date and Time of the missed call 


7.4.10.5.1.4 


05H 


Line name 


>2 


Name of line on which the call was 
received/passed (cannot be empty) 


7.4.10.5.1.6 


06H 


Line id 


>3 


Id of line used for the call 


7.4.10.5.1.7 


NOTE: For outgoing calls, 'Number' is always known and its length shall be greater or equal to 2. 
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'Number' field: If the 'call type' is 'outgoing', the FP shall store the digits part of the called party number. However, the 
FP should not store digits dialled by the user after end to end connection has been established with called party (i.e. 
after 'CS call connect' is sent to the PP). 

'Line id field': The FP shall implement the 'Line id' and Line name' fields in the list even if the multiple line feature 
[NG1.N14] is not implemented in the FP (systems with only 1 line). 

Field identifiers from 07H to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

Entry merging strategy: The same approach as for the 'Outgoing call' list shall be used, except that it applies to calls 
of the same type, with a given external party and on a given line. Please refer to clause 7.4.10.5.4 Outgoing Calls List 
entry field, 'Entry merging strategy' entry. 

Display of fields: 

Minimum requirement: a PP implementing the present list shall display at least 'Call type', 'Number' or 'Name' and 'Date 
and Time' fields. 

Display recommendations specific to each 'call type' are also available in the clauses for the related lists and should be 
taken into account also for the All Calls List. 

Additionally as many other fields as possible should be displayed. The way these fields are displayed is left free to PP 
implementation (for example other fields accessible only when viewing details of an entry). 

7.4.10.5.7 Contact List entry fields 

This list contains the Contact List (or phone book) for the complete DECT system. 



Table 69: Contact List entry fields 



Field 


Field 


Length 


Normative action/comment 


Clause 


identifier 




constraint 






01H 


Name 


> 1 


Name of the contact (last name) 


7.4.10.5.1.3 


02H 


First name 


> 1 


First name of the contact 


7.4.10.5.1.10 


03H 


Contact number 


> 1 


Number of the contact (see note) 


7.4.10.5.1.11 


04H 


Associated 
melody 


> 1 


Ringing melody used for the contact 


7.4.10.5.1.12 


05H 


Line id 


> 2 


Id of line used for the call 


7.4.10.5.1.7 


NOTE: Contact number is a multiple instance field of the Contact List. 



'Associated melody': The Associated melody' defines the melody which is used when an incoming call is received 
from the number in the 'Contact number' field, or from one of the numbers in the case of multiple 'Contact number' field 
instances. It allows to select the melody on FP and potentially on PP side. 

• The support of this field by the FP is optional. The PP may know the presence of the field via the 'query 
supported entry field' command. The FP may implement this field in two cases: 

Use case 1: when FP has configurable ringing capabilities. 

Use case 2: in order to personalize the melodies used on PP side but based on the Contact List in the FP. 
This use case may come in addition to use case 1 . 

When not implemented, the field is not included in any entry of the list. 

The support of this field by the PP is also optional. 

Use of the field by the FP: if the FP has ringing capabilities, the FP may use it to select the melody to be played on FP 
side. This melody overrules the 'FP melody' field in the Line Settings List. In other words, the FP plays this melody 
instead of the default melody defined for this line. The volume to be used by the FP shall be the volume defined in the 
corresponding Line Settings List entry 'FP volume' field. 
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If the FP uses the field 'associated melody' to select the FP melody it should also implement 'FP melody' and 'FP 
volume' fields in the Line Settings List. 

Use of the field by the PP: fhis field may also be used by the FP to send ring pattern in «SIGNAL» IE to the PP. In 
that case, '01 H value stands for 'Alerting on - pattern 1', '02 'H stands for 'Alerting on - pattern 2', and so on. In this case, 
only values up to '07'H may be transmitted to the PP. 

This field may also be set to 'undefined value' (see clause 7.4.10.5.1.12). In this case, the FP shall use its default melody 
(optionally defined in the Line Settings List. 

Signal value coding: 

As defined in clause 7.4.18, if the FP implements the 'associated melody field' and an associated melody field is defined 
for a given contact, the FP shall set the «SIGNAL» IE on incoming call toward PPs declaring the 'support of 
associated melody per contact' capability bit to the correct corresponding value: 

• Alerting on - pattern 1' if melody 1 is configured as associated melody. 

• Alerting on - pattern 2' if melody 2 is configured as associated melody. 

• And so on for other melodies up to Alerting on - pattern 77melody 7. 

NOTE 1: Alerting on pattern 0' is reserved for internal call and not foreseen to be used as associated melody to a 
contact. 

'Line id field': The FP shall implement the Line id' field in the list even if the multiple line feature [NG1.N14] is not 
implemented in the FP (systems with only 1 line). 

If the entry is related to all lines in the system, the field Line id/subtype' shall be set to All lines'. 

'Contact number field': The FP shall implement at least two contact number fields per entry in the Contact List. The 
PP shall make accessible to the user at least one contact number per entry of the Contact List (the first one in the entry). 
(However, the PP shall save the same number of 'contact number' instances in the 'save entry' command as received in 
the 'edit confirm' command (see 'save entry command' clause 7.4.10.4.5.1)). The PP may know the number of 'contact 
number' supported by the FP via the 'query supported entry fields' command. 

NOTE 2: From implementation point of view, three contact numbers per entry are recommended on FP side. Each 
contact number may be of any type (fixed, mobile or work). 

Field identifiers from 06H to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

Display of fields: 

Minimum requirement: a PP implementing the present list shall display at least 'Name' and 'Contact number' fields (at 
least one contact number see previous subsection). 

When displaying contact numbers, the PP shall respect the order in which they are transmitted by the FP during the 
'read entries' or 'edit entry' command data packets. 

EXAMPLE: If the FP provides 3 contact numbers within its data packets for an entry in the following order 
contact number A first, then contact number B and contact number C, PP shall display contact 
number A then possibly contact number B then possibly contact number C. 

NOTE 3: If a further 'save entry command' is performed by the PP on this entry, the PP should be careful about the 
order of these fields within the command. Possible re-ordering of the fields by the PP, will lead to a new 
display order when any PP reads this entry later. 

NOTE 4: PP implementations should avoid saving an empty contact number as first contact number of the entry, 

while other contact numbers of the entry (second and third for example) are filled with values. Otherwise 
another PP with only 1 contact number display capability will not display any contact number for this 
entry. 
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Additionally as many other fields as possible should be displayed. The way these fields are displayed is left free to PP 
implementation (for example other fields accessible only when viewing details of an entry). 

7.4.1 0.5.8 Internal Names List entry fields 

This list contains the names of registered PPs of the complete DECT system. 



Table 70: Internal Names List entry fields 



Field 
identifier 


Field 


Length 
constraint 


Normative action/comment 


Clause 


01H 


Number 


> 2 


Terminal identity number 


7.4.10.5.1.2 (see note 1) 


02H 


Name 


> 2 


Name of the internal party 


7.4.10.5.1.3 


03H 


Call interception 


= 2 


Call interception allowed or not 


7.4.10.5.1.13 (see note 2) 


NOTE 1: Clause 7.4.10.5.1 .2.1 specifies the coding of terminal identity numbers. 

NOTE 2: 'Call interception' field is relevant for each PP (especially headset PPs) (see clause 7.4.16). 



One and only one entry per terminal identity number shall exist in the Internal Names List. A PP is not allowed to 
modify the 'number' field using edit and save commands'. If a PP attempts to do so, the FP shall reject it after the save 
with negative acknowledgement and reject reason 'procedure not allowed' (as defined in clause 7.4.10.4.5.2). 

When a PP registers to the FP, the FP shall automatically add a corresponding entry in the Internal Names List (see 
clause 7.4.11.2) with: 

• an assigned 'number' (terminal identity number). Editable property bit of the field set to 0B (field not editable); 

• a default name. (For example 'DECT ri where n stands for the terminal identity number in decimal 
representation); 

• the 'Call interception' field set to 'allowed' as default value. 

When displaying its name in idle, the PP should avoid displaying also the terminal id number. 

NOTE: This provision avoids misleading displays such as 'DECT 1 1' for terminal 'DECT 1' followed by terminal 
id number '1' that could be mistaken for terminal 'DECT 1 1' (terminal id number eleven). 

It is however recommended to display both when the user of the PP reads the Internal Names List itself. 

EXAMPLE 1 : The list of handsets displayed on the PP may look as follows: 

1: DECT Phone 1 
2: DECT Phone 2 

Additionally the FP shall send a list change notification for the Internal Names List in order to inform all PPs that the 
number of PPs in the Internal Names List has been changed (see clause 7.4.10.2.2). 

The user may later edit the 'Name' and 'Call interception' fields (when editable). Editing of fields in the Internal Names 
List may however be 'PIN protected' as described in the 'PIN code' entry in clause 7.4. 1 1 . 1 . 

EXAMPLE 2: The user may set the value of the 'Call interception' field to 'Not allowed' if he wants to prevent 
any call on this specific PP from being intercepted. 

When the PP is consulting the Internal Names List, the FP shall dynamically set to 1 the 'Own' property of the 'Number' 
field of the entry corresponding to this PP. It is recommended that the PP use this mechanism in order prevent the user 
from placing an internal call towards its own PP. 

EXAMPLE 3: If the user initiates an internal call from PP1 and PP1 uses the Internal Names List for displaying 
the list of remote parties to the user, PP1 is able -thanks to the own property- to prevent a call to 
PP1 and to allow an internal call only towards PP2, PP3 . . .PPn. PP1 may prevent a call to PP1 by 
not displaying PP1 in the list, or by any other means. 

If a call is nevertheless attempted by a PP towards itself, the FP shall release the call properly. 

Field identifiers from 04H to 80H are reserved for further standardization and shall not be used. 
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Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

Display of fields: 

Minimum requirement: a PP implementing the present list shall display at least 'the 'Name' field. Furthermore the PP 
shall make accessible and editable the 'Call interception' field. 

Additionally as many other fields as possible should be displayed. The way these fields are displayed is left free to PP 
implementation (for example other fields accessible only when viewing details of an entry). 

7.4.10.5.9 "DECT System Settings List" entry fields 

See clause 7.4. 11.3. 

7.4.10.5.10 "Line Settings List" entry fields 

See clause 7.4.11.4. 

7.4.1 0.5.1 1 All Incoming Calls List entry fields 

This list contains all the incoming calls, including both accepted external incoming calls and missed external calls, 
occurring on any line of the DECT system. All Incoming Calls List entry fields are the same as Missed Calls List entry 
fields, see clause 7.4.10.5.3. 

For an incoming accepted call entry in the All Incoming Calls List: 

• the 'Read status' field value shall be set to '0'; 

• the 'Number of calls' field value shall be set to 1 . 

NOTE: As the 'incoming accepted call' list does not have a 'Number of calls' field, the 'Number of calls' field is 
always T here, whatever the merging strategy used for the Incoming Accepted Calls List (see 
clause 7.4.10.5.5). 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

Display of fields: 

Minimum requirement: a PP implementing the present list shall display at least 'Number' or 'Name' and 'Date and Time' 
fields. 

If the 'Number' field is empty (length set to 1), e.g. no CLIP was received from the network, the PP should display 
'unknown' as field value (translated in the language used by the user) instead of displaying nothing. 

If the 'Name' field is empty (length set to 1) e.g. no CNIP was received and no matching Contact List entry exists; see 
clause 7.4.10.5.1.3), the PP should display an explicit string (e.g. 'unknown') as field value (translated in the language 
used by the user) instead of displaying nothing. 

Additionally as many other fields as possible should be displayed. The way these fields are displayed is left free to PP 
implementation (for example other fields accessible only when viewing details of an entry). 

7.4.1 0.6 List access service call and interactions with voice calls 

This clause describes list access setup general considerations, and the interactions between the list access service and a 
voice call using the same DECT NWK layer C/O service instance (the same 'call' from DECT NWK layer point of 
view). 

A list access session can be started by a PP either in idle mode or already involved in a call. For this version of the 
standard, the List access service shall only use the C s channel. 

As the C F channel shall not be used for this version of the standard, the FP capability bit a 26 shall be reset. 
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The following use cases are covered in this version of the present document: 

• The PP in idle mode starts a list access session on C s channel. 

• The PP in idle mode starts a list access session on C s channel and then places a voice call. The list access 
session, if not closed, continues on C s channel. 

• The PP in idle mode starts a list access session on Cs channel and then receives (and accepts) a voice call 
during the list access session. The list access session, if not closed, continues on C s channel. 

• The PP starts a list access session during a voice call on C s channel. 
As a consequence: 

• PP and FP shall support "List access setup" as described in clause 7.4.10.6.1. 

• PP and FP shall support "List access with possible first voice call initiation" as described in clause 7.4.10.6.2. 

• PP and FP shall support "Incoming voice call during existing list access session" as described in 
clause 7.4.10.6.3. 

• PP and FP shall support "List access during existing voice call with possible second call initiation" as 
described in clause 7.4.10.6.4. 

• The PP and FP shall support procedure "Switching between LiA session and voice call" of clause 7.4.10.6.5. 

• The PP and FP shall support procedure "Returning to LiA session after voice call termination" of 
clause 7.4.10.6.6. 

In addition, the FP shall temporarily restrict access to some of the lists during a voice call (DECT system, line setting 
and Internal Names Lists), in order to ensure the integrity of the system while it is used. In this case, FP shall prevent 
from modifying the requested list entry (negative acknowledgement with reject reason 'temporarily not possible') until 
the voice call is released. In other words, FP shall temporarily prevent "edit entry", "save entry" and "delete entry" 
commands for some entries, as well as "delete list" command. PP shall support such answers when requesting those 
commands on any of the 3 lists. 



7.4.10.6.1 List access setup 

The list access service can be used, and all lists may be accessed, whatever the call class of the underlying call. In other 
words, the <call class> field value of the «basic service» I.E. used at call setup may be 'Normal call setup', Internal 
call setup', or LiA service call setup' defined in EN 300 175-5 [5], clause 7.6.4. 

However, the following rules shall be fulfilled: 

1) If the PP was idle when starting a list access session, it shall use call class LiA service call setup', the <basic 
service> "wideband speech default" and the default setup attributes defined in clause E.2 of EN 300 175-5 [5]) 
because this service call may end up into a voice call. 

2) If the PP was already involved in a voice call (internal or external) when starting a list access session, it shall 
continue using the same call and call class. 

In cases 1 and 2, no call id shall be assigned for the LiA service call. 

In case 1, the LiA service call is not connected ({CC-CALL PROC} is used, but no {CC-CONNECT} is used). 
{CC-CONNECT} is only used if a voice call is subsequently connected. The LiA service call shall be connected later 
only when a voice call is processed. 

If the PP was idle when starting a list access session, it shall initiate a first call using {CC-CETUP} and call class LiA 
service call setup': 

• the C s channel shall be used; 

• the FP shall immediately answer with a {CC-CALL-PROC}, without call status nor call id. No call id shall be 
assigned to the LiA service call; 
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• the 100 second timer F<CC.04> / P<CC.04> defined in EN 300 175-5 [5], clauses 9.3.1.5 and 9.3.1.6 for a 
{CC-CALL PROC} message shall not apply in this case on PP side, nor on FP side. 

Inactivity timer PP: 

The PP shall implement an inactivity timer mechanism intended for not leaving list access sessions opened for ever on 
FP side. 

If the PP is not involved in a call and no activity is detected on PP side during a certain time on the list access, once list 
access session is started, PP shall immediately release the call by sending a {CC-RELEASE} and stop the timer. 

If the PP becomes additionally involved in a voice call, the inactivity timer may be stopped. It shall be re-started after 
the end of the voice call if the list access is still opened. 

NOTE 1: A possible implementation is that the PP re-starts the timer, each time a list access command is sent by 
the PP and each time user activity is ongoing in the list on PP side (for example up/down scrolling in a 
list without any list access command sending). 

NOTE 2: Value of the timer is left free to implementation. However it is recommended that the inactivity timer 
value is no more than 300 seconds. 

List access maintain call timer FP: 

The FP shall implement a list access maintain call timer mechanism intended for maintaining the call for a short period 
of time after the reception of an "end session" command from the PP. 

This timer is started after the FP has received an "end session" command from the PP for the last active list access 
session if all call identifiers related to this PP are in "CS idle" call status. When the timer is running the FP shall 
maintain the connection and shall not release it by sending {CC-RELEASE} or {CC-RELEASE-COM}. 

The timer is stopped upon reception of any CC-message from the PP, e.g. a {CC-INFO} or {CC-RELEASE} message. 
On expiry of the timer the FP may but need not release the call. 

The value of the timer is left free to implementation, however it shall not be less than one second. 

7.4.1 0.6.2 List access with possible first voice call initiation 

The provisions of clause 7.4.10.6.1 shall be respected. Additionally, if the list access session is intended to establish a 
first voice call: 

• The PP shall initiate a pseudo outgoing parallel call by using the "Outgoing parallel call initiation" procedure 
(see clause 7.4.3.5.1) with the following modifications: 

The PP is using the number (external or internal) read from the list access session, sent in a single 
CC-INFO message ('1C15'H/'17'H + called number) along with a line identifier. 

• The PP may close the list access session, by using the 'End session command' (see clause 7.4.10.4.1.3), just 
before or after the CC-INFO has been sent. In both cases the FP shall maintain the call (see also "List access 
maintain call timer FP" in clause 7.4.10.6.1). 

NOTE 1: Actually the PP is using the outgoing parallel call initiation procedure, in order to establish a first call, 
because the link was already established when starting the list access session. 

NOTE 2: There is at this point an implicit change of call class, from LiA service call setup' to 'Normal call setup', 
or to Internal call setup'. 

• The FP shall immediately answer with a CC-CONNECT, along with a default codec if it was not sent 
previously in CC-CALL-PROC, in order to connect the U-plane (active audio path). This allows to handle the 
rest of the voice call as a pseudo outgoing parallel call. Neither call id nor call status nor line id are sent along 
with CC-CONNECT, as they are sent in subsequent CC-INFO as for regular outgoing parallel call. 

• The FP shall then send the appropriate call status (most likely 'CS call proc') in a subsequent CC-INFO 
message, with the newly assigned call id. 



ETSI 



202 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



The codec negotiation shall be carried out as for a normal first outgoing voice call, (optional 
«CODEC-LIST» sent in {CC-SETUP}, mandatory «CODEC-LIST» with a single codec sent (once) by 
the other side with «PROGRESS-INDICATOR» at the latest (if used), or in {CC-CONNECT}. See 
TS 102 527-1 [21], clause 7.3.3). This means that a default codec is chosen by the FP at latest in 
CC-CONNECT. 

If the default codec is not suitable for the voice call, a codec switching may be initiated by the FP. In this case, 
this will very probably be performed between the outgoing parallel call initiation by the PP, and the sending of 
the 'CS call connect' call status by the FP. 

If the PP left the list access session open, the FP and PP shall comply with procedure "Switching between LiA 
session and voice call" of clause 7.4.10.6.5. 

In order to return to the LiA session at the end of the voice call if it remained open, the PP and FP shall use the 
procedure "Returning to LiA session after voice call termination" of clause 7.4.10.6.6. 
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PP 



FP 



CC-SETUP 



« BASIC SERVICE, < Call class ■■ 

» 



'LiA service call' > 



CC-CALL-PROC 



NO «CALL-INFORMATION» here, because 

no call id is used for a list access service call 
no 'CS call proc' call status either 



Service call: 
No call id used 



No CC-SETUP-ACK 



LiA session started 
Number found. 



Pseudo outgoing parallel call initiation used for 
first call 

CC-INFO 



« MULTI-KEYPAD, < Keypad info = '1 C1 5/1 7'H + 'calle i number' > 



PP possibly ends the LiA session 



CC-CONNECT 



« CODEC-LIST: 



If still open, LiA session continues on Cs channel 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '03'H > 

< id type/subtype = 'Call status', value = 'CS call proc' 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call alerting' > 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = '03'H > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call connect' > 



no call hold in 



U-plane open 
(local connection) 



Call id 

assignement 



network message 
'peer party is alerting' 



network message 
'peer party is active' 



Figure 56: List access with possible first voice call initiation 

NOTE 3: For conciseness of figure 56, line identifier is not represented. 
NOTE 4: Codec confirmation can be also performed in CC-CALL-PROC. 
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7.4.1 0.6.3 Incoming first voice call during existing list access session 

If an incoming voice call is received when the PP is involved in a list access session: 

• The FP shall first answer with a CC-CONNECT along with a default codec, in order to connect the U-plane 
(active audio path). This allows to handle the incoming voice call as a pseudo call waiting. Neither call id nor 
call status nor line id are sent along with CC-CONNECT, as they are sent in subsequent CC-INFO as for 
regular call waiting (and actually for a first incoming call, the CC-CONNECT would be in the other direction). 

NOTE la: At this stage, the {CC-CONNECT} message could cross a {CC-RELEASE} message from PP, if PP or 
PP user releases the LiA service call simultaneaously. See below 'Crossing with LiA service call release 
from PP side' subsection. 

• The FP shall present a pseudo call waiting to the PP by using the "Call waiting indication" procedure (see 
clause 7.4.3.5.2) in order to present the incoming call to the PP (including the call id for this call). 

NOTE 1: The call waiting indication procedure is used here for presenting a first call, because the link was already 
established when starting the list access session. 

• The PP shall present the incoming call to the user. For example by ringing as for an incoming first call. 

• The FP shall also present the incoming call as a first call to any other idle PP. 

• If the user accepts the call, the PP may close the list access session, prior to sending the call waiting 
acceptance, by using the 'End session command' (see clause 7.4.10.4.1.3). 

• The PP and FP shall support all call waiting related parallel call procedures defined in clause 7.4.3.5 in order 
to handle the pseudo call waiting (including the handling of call id, call statuses, exception cases, etc.). More 
specifically: 

If the PP wishes to answer the incoming call, it shall use the "Call waiting acceptance" procedure 
(see clause 7.4.3.5.6), with the following modifications: 

■ The FP shall send the 'CS call connect' call status (with the call id) in a subsequent CC-INFO 
message. 

■ As the procedure is used here for a first call, the FP shall not send back any 'CS call hold' call status 
to the PP (no call to be put on hold). 

If the PP wishes to reject the incoming call, it shall use the "Call waiting rejection" procedure (see 
clause 7.4.3.5.7), with no modification: 

■ The handling is similar to clause 7.4.6.6 "returning to LiA session after voice call termination" 
(case where PP hangs up the call). FP shall mute the audio. 

NOTE 2: There is at this point an implicit change of the call class, from 'LiA service call setup' to 'Normal call 
setup', or to Internal call setup'. 

• The codec negotiation shall be carried out as for a first outgoing voice call (although we are in an incoming 
voice call scenario): optional «CODEC-LIST» sent in {CC-SETUP}, mandatory «CODEC-LIST» with 
a single codec sent (once) by the other side with «PROGRESS-INDICATOR» at the latest (if used), or in 
{CC-CONNECT}. See TS 102 527-1 [21], clause 7.3.3). This means that a default codec is chosen by the FP 
at latest in CC-CONNECT. 

• If the default codec is not suitable for the voice call, a codec switching may be initiated by the FP. In this case 
this will very probably be performed between the call waiting acceptance by the PP and the sending of the 'CS 
call connect' call status by the FP. 

• If the PP left the list access session open, the FP and PP shall continue using the C s channel for the list access 
session. 

• In order to return to the LiA session at the end of the voice call if it remained open, the PP and FP shall use 
procedure "Returning to LiA session after voice call termination" of clause 7.4.10.6.6. 
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PP 



CC-SETUP 



FP 
-> 



« BASIC SERVICE, < Call class = 'LiA service call' > » 
CC-CALL-PROC 



NO «CALL-INFORMA TION» here, because 

no call id is used for a list access service call 
no 'CS call proc' call status either 



Service call: 
No call id used 



No CC-SETUP-ACK 



LiA session started 



U-plane open 
(local connection) 



PP presents 
call to the user 



If incoming call 
external 



LiA session 
termination may 
not be user 
initiated (PP 
implementation) 



CC-CONNECT 



Pseudo call waiting used for first call 

CC-INFO 



« SIGNAL value = 'call waiting tone' = '07'H » 
« CALLING PARTY NUMBER, 'calling number' > » 
« CALL-INFORMATION, 
< id type = 'Line id', subtype = 'external call', value = 'waiting ca|l line id' > 

< id type/subtype = 'Call identifier', value = 'waiting call id' = '02'H 

< id type/subtype = 'Call status', value = 'CS call setup' > 



PP possibly ends the LiA session 



call waiting acceptance 

CC-INFO 



« MULTI-KEYPAD, info = '1C 35'H » 

« CALL-INFORMATION, 'Call identifier' = 'waiting call id' 



If still open, LiA session continues on Cs channel 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'waiting call id' 

< id type/subtype = 'Call status', value = 'CS call connect' 



Incoming voice call 



If required by the 
'Tones provision' 



In multiple call mode, 
other handsets stop 
ringing or receiving 
the CW indication 
02'H > » 



network message 
'peer party is active' 



'02'H > End to end 
connection for 
the voice call 



Figure 57: Incoming first voice call during existing LiA session, connected in the same call 

NOTE 3: For conciseness of the figure neither line identifier nor codec negotiation are represented. 

Crossing with LiA service call release from PP side. If the PP, or PP user, sends a {CC-RELEASE} message for 
releasing the LiA service call at the very time when the FP sends the {CC-CONNECT} message, the FP shall: 

Confirm the release of the LiA service call by sending a {CC-RELEASE-COM} message to the PP 

Re -present the incoming call as a normal first call 
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PP 



FP 



PP user 
ends the LiA 
service call 



CC-SETUP 



« BASIC SERVICE, < Call class = 'LiA service call' > » 



CC-CALL-PROC 



LiA session started 



CC-RELEASE 



Crossing of release 
with U-plane 
connection 



CC-CONNECT 




CC-RELEASE-COM 



FP re-presents first call out of LiA session 
CC-SETUP 



« CALLING PARTY NUMBER, 'calling number' > » 
« CALL-INFORMATION, 

< id type = 'Line id', subtype = 'external call', value = u > 

< id type/subtype = 'Call identifier', value = 02H > 

< id type/subtype = 'Call status', value = 'CS call setup' > 



FP intends to 
present 
incoming first 
voice call 
as pseudo call 
waiting within 
LiA service call 



The FP solves 
the conflict by 
confirming the 
release 



Figure 57a: {CC-CONNECT} and {CC-RELEASE} crossing use case 



7.4.1 0.6.4 List access during existing voice call with possible second call initiation 

This procedure illustrates the use of a regular parallel call initiation where a second call is setup when a list access 
session and a voice call were already established in parallel. 

NOTE: This is in contrast to clause 7.4.10.6.2 which uses a pseudo outgoing parallel call initiation. 

If the PP was already involved in a voice call (internal or external) when starting a list access session (e.g. contacts list 
consultation for a parallel call initiation use case): 

• the PP shall comply with procedure "Switching between LiA session and voice call" of clause 7.4.10.6.5 when 
starting the LiA session; 

• the FP shall not assign any call id for the list access session. 

Additionally, if the list access session is intended to establish a parallel voice call, and when the number to be called 
has been found: 

• the PP shall use procedure "Switching between LiA session and voice call" of clause 7.4.10.6.5, in order to 
handle the switching from the LiA session to the first active voice call; 

• the PP shall use the "Outgoing parallel call initiation" procedure (see clause 7.4.3.5.1) using the number 
(external or internal) read from the list access session; 

• the PP may close the list access session, by using the 'End session command' (see clause 7.4.10.4.1.3), just 
before or after the CC-INFO (initiating the parallel call) has been sent. In both cases the FP shall maintain the 
call (see also "List access maintain call timer FP" in clause 7.4.10.6.1). 



ETSI 



207 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



PP 



FP 




Optionally 
put the 
ongoing 
call on- 
hold 



Outgoing 
parallel call 
initiation with 
number 



If not 
already 
done 
before 



Ongoing call (external or internal, call id=1) 



CC-INFO 



« MULTI-KEYPAD, info = '1 C 41 'H » 

« CALL-INFORMATION, 'targeted call id' = '01 'H > » 

CC-INFO 



« CALL-INFORMATION, 'targeted call id' = '01'H > 
< 'Call status' 'CS call hold' > » 



LiA session started / Number found. 



CC-INFO 



Regular second call 
« MULTI-KEYPAD, < Keypad info = '1 C1 5/1 7'H + 'called ^umber' > 

PP possibly ends the LiA session 



CC-INFO 

+ 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 

CC-INFO 



As described 
in 7.4.10.6.5 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '03'H > 

< id type/subtype = 'Call status', value = 'CS call proc' > 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '03'H > 

< id type/subtype = 'Call status', value = 'CS call 
alerting' > » 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '03'H > 

< id type/subtype = 'Call status', value = 'CS call 
connect' > » 



Call id 

assignement 
here 



network message 
'peer party is alerting' 



network message 
'peer party is active' 



Figure 58: List access during existing voice call with second call initiation 
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7.4.1 0.6.5 Switching between LiA session and voice call 

This procedure is used when a list access session is open on C s channel and a voice call is active in parallel. 
The following rules shall be applied: 

• if the voice call is started while a list access session was already open, the FP and PP shall continue using the 
C s channel for the list access session. The voice call initiation (incoming or outgoing) is described in other 
procedures; 

• the list may be accessed any time during the voice call, through IWU to IWU messages; 

• the U-plane always remains connected for the duration of the call; 

• if a list access session is started while a voice call is active, the voice call may be put on hold; otherwise, the 
voice path with the remote party remains open. 

NOTE: If the LiA session is open for starting a second call (Contact List consultation), putting the active call 
on-hold only anticipates what will happen when the second call will be initiated. 

7.4.1 0.6.6 Returning to LiA session after voice call termination 

This procedure is applicable only if a LiA session is still opened at the time a voice call is terminated. 

NOTE: For example this procedure is not applicable if the PP decides to close the LiA session before hanging up 
the voice call. A simple CC-RELEASE can be used in this case. 

There are two cases of voice call termination while leaving the LiA open: 

• If the remote party hangs up, the FP shall release the call using 'CS idle' as defined in clause 7.4.3.5.4, but shall 
not release the link. 

• Additionally, the PP may terminate the voice call and leave the list access session active by using a call release 
request as defined in clause 7.4.3.5.4. In that case, the PP shall re-start the inactivity timer when sending the 
call release request. 

In both cases, when the voice call is terminated: 

• the FP shall maintain the link until the list access session is closed; 

• the U-plane shall remain open; 

• and the audio shall be muted (FP shall send mute pattern as defined in TS 102 527-1 [21], annex B and ignores 
the audio received from the PP). 
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PP 



FP 




If the PP 
hangs up 



Ongoing call (external or internal, call 
id=1) 




Call release request 

CC-INFO 



« MULTI-KEYPAD, info = '1C 33'H » 



CC-INFO 



Absent if the 
remote party 
hangs up 



« CALL-INFORMATION, 'targeted call id' = '01'H > 
< id type/subtype = 'Call status', value = 'CS idle' > 



IWU to IWU session continued 



OT3 



Figure 59: Returning to LiA session after voice call termination 

7.4.1 0.7 Generic sequence charts for list access 

See clause B.3 for examples of sequence charts for list access. 

7.4.1 0.8 Use case examples for list access 

See clauses C.5, C.6, C.7 and C.8 for examples of use cases for list access. 

7.4.1 1 DECT system and line settings 

7.4.1 1 .1 DECT system and line settings considerations 

DECT system and line settings shall use the "List access service" procedures with the following additional 
requirements. 

DECT system settings consist of a set of settings that are valid for the complete DECT system, i.e. valid for all 
registered PPs independently of line / multiple line concepts. They are stored in the FP as a unique list with only one 
entry in the list. Each setting is a field of this entry. 

Line settings consist of a set of settings that are valid for one line of the DECT system, i.e. valid for all registered PPs 
attached to this line. They are stored in the FP as a unique list with one entry per line in the list. Each setting is a field of 
this entry. Even if the DECT system does not implement multiple line features, the FP and PP shall support line settings 
with only one entry: the settings for the only line supported by the system. 

Sorting of the lists: 

No sorting is defined for the DECT System Settings List, as it contains only one entry. 

The Line Settings List is sorted by ascending line id number. 

Commands: 

All the "List access service" feature commands shall be supported for the "DECT system and line settings" feature, 
except for: 



• The "delete entry" command is not allowed for the DECT System Settings List. 
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The "delete list" command is not allowed for the DECT System Settings List, nor for the Line Settings List. 

These commands shall not be invoked by any PP and shall be answered with negative acknowledgement from the FP 
with reject reason "procedure not allowed" (see clause 7.4.10.4.9). 

Saving a new line setting entry or deleting a line setting entry is allowed (when creating or removing a line for the 
DECT system). Please refer to clause 7.4. 1 1 .2 "Interactions between registration, attachment of handsets and lists" for 
impacts. 

Only one entry per line identifier shall exist in the Line Settings List. In other words, two distinct entries shall never 
have the same line id (see clause 7.4.11.3 for details). 

Settings (fields of DECT system and Line Settings Lists): 

Some DECT system or line settings are mandatory and shall be supported both by the FP and the PP. Please refer to 
clause 6.10, table 9 for status of each setting. When a setting is mandatory in the table, the related field is mandatory 
and shall be implemented in the PP and the FP. 

The PP may use the "Query supported entry fields" procedure (see clause 7.4.10.4.2) to know which settings (fields) are 
supported by the FP. The FP shall answer with mandatory and optional settings implemented in the FP. This way, the 
PP will be able to give proper indication to the user (when accessing the settings menus for example). 

All settings shall have default value set when product is manufactured. Some of these settings may be reset to default 
value with the "Base reset" setting. Please refer to tables 72 and 73 for details. 

For some specific settings, a PP may request the reset of the setting/field by setting the field length to 1 (only octet 3 
available in entry field). The field itself is not removed from the FP list entry. See "Field instance deletion or resetting 
with a save entry command" in clause 7.4.10.4.5. It has to be noted that resetting some fields in some lists can be 
dangerous and should be carefully controlled by the PP (FP IP address for example). 

The PP may modify 1 to n setting(s) by using an "Edit entry" command with the following parameters: (session 
identifier, entry identifier=l, 1 to n field identifiers). 

PIN code: 

For security reasons, the PIN code shall never be sent over the air on a non ciphered link. Moreover, the FP shall 
prevent a non-allowed PP to save a new PIN code: 

The PIN code is used-among other uses-to protect a list against: 

• unauthorised modifications of some or all of its fields; 

• unauthorised addition or deletion of field instances (for 'PIN protected' multiple instance fields); 

• unauthorised resetting of PIN protected fields (for 'PIN protected' single instance fields); 

• unauthorised entry deletion for an entry including at least one PIN protected field (and when such deletions are 
allowed, see tables 41 and 42). 

NOTE 1: The 'DECT system settings' list does not allow entry deletion, as indicated in tables 41 and 42. 

NOTE 2: None of the following lists allow list deletion, as indicated in tables 41 and 42. 

The present document provides PIN protection for fields in the following lists only: 

• DECT System Settings List (including the PIN code itself). 

• Line Settings List. 

• Internal Names List. 

The reading of fields is not protected. The PIN code itself (DECT System Settings List) is not readable, even after 
successful PIN authentication (an invalid value is returned in any case). 
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For each of the lists above, the subset of fields that require protection is left free to the implementer. If the FP requires 
'PIN protection' for a field, it shall set to T the 'PIN protected' property of that field when sending it to the PP. 

However, the FP shall always PIN protect the 'New PIN code' field of the 'DECT system settings' list. 

For the PIN code value, two distinct fields are defined in the 'DECT system settings' list, which are both protected 
against reading: 

• the 'Current PIN code' field is only used to check the PIN code entered by the user. As it is not directly 
modifiable, it is not considered as 'PIN protected'; 

• the 'New PIN code' field is used to modify the PIN code and is therefore always 'PIN protected'. 

At least when accessing either the 'Current PIN code' or the 'New PIN code' setting of the "DECT system settings" list, 
with an edit or save command, the connection shall be ciphered; i.e.: 

• for "Edit entry confirm", "Save entry" and "Save entry confirm" commands that includes the PIN code fields 
'Current PIN code' and 'New PIN code' in data packets, the DECT link shall be ciphered prior to the command; 

• if this not the case, the FP shall answer with a negative acknowledgement, with reject reason = "procedure not 
allowed" (see clause 7.4.10.4.9). 

For the 'Current PIN code' and 'New PIN code' fields of the 'DECT system settings' list, and after any Edit 
entry' or 'Read entry' command on any of these two fields: 

• the FP shall answer with the invalid value 'FFFFFFFF'H, instead of the real value of the field. 

For any 'PIN protected' field of the DECT System Setting List, Line Setting List, or Internal Names List 

(including the 'New PIN code' field of the 'DECT system settings' list): 

• before saving a new value for that PIN protected field, the PP shall: 

open a (parallel) list access session with the 'DECT system setting' list, if such a session does not already 
exist (i.e. if the field to protect is not from that list); 

perform the 'Edit entry' and 'Save entry' commands on the 'Current PIN Code' field of the 'DECT system 
setting' list: 

■ The 'Save Entry' command shall include only the current PIN code field and no other field. 

■ After the 'Save Entry' command, the FP shall compare the received value with the stored value of 
the field, but the FP shall not modify this stored value. 

■ If the entered PIN code is correct (the 'Save Entry' command was successful), the FP shall allow the 
PP to save a new value for the PIN protected field in the same call via the "Save entry" command. 

■ If the entered PIN code is incorrect, the FP shall answer with a negative acknowledgement with 
reject reason 'incorrect PIN'. 

• when using a 'Save entry' command for modifying the value of that PIN protected field: 

If the field to be modified is the 'New PIN code' field, the new value shall be stored in both the 'Current 
PIN code' and 'New PIN code' fields. 

As soon as there has been a 'DECT system settings' list access session with correct PIN authentication in 
the current call all subsequent modifications on any of the three lists are allowed during the same call. 

In all cases, if the 'Save entry' command occurs at a point in time where, in the same call: 

■ there has been no successful save of the 'Current PIN code' field before; or 

■ there has been an unsuccessful save of that field before; 

■ the FP shall answer with a negative acknowledgement with reject reason 'PIN code required'. 
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• For the 'Line Settings List and Internal Names Lists and after a delete entry command is attempted on an 
entry with 'PIN protected fields', the FP shall require prior correct PIN entry in the same call as described 
above for entry modification. 

Access to the "DECT system settings" menu on the PP may be conditioned to prior PIN code keyboarding and may be 
completely in ciphered mode. This is left free to the implementer. 

See clauses C.7.2, C.7.4 and C.8.4 for examples of use cases related to PIN code and PIN code protected fields. 
Initial value: 

The "DECT system settings" list unique entry is at position index 1 in the DECT system list. 
First Line Settings List entry is at position index 1 in the Line Settings List. 

7.4.1 1 .2 Interactions between registration, attachments of handsets and lists 

Internal Names List fully reflects the registered PPs. At registration of a handset, the FP shall add a new entry in the 
Internal Names List with a default name. Additionally, the FP shall send a list change notification for the Internal 
Names List to all PPs (see clause 7.4.10.2.2). 

With a "mono-line" FP, the FP shall automatically attach the PP to the unique line, "Attached handsets" setting in the 
Line Settings List entry shall also automatically be updated by the FP with corresponding bit set. 

With a "multiple lines" FP (FP connected to several lines and implementing the multiple lines feature [NG1.N.14], the 
FP should automatically attach the registered PP to at least one line (i.e. update "Attached handsets" setting in at least 
one entry of the Line Settings List). This default attachment may be later updated by the PP or done on FP side 
(e.g. through a web interface). Other implementations are allowed (i.e. attaching the PP to all lines by default). 

Except during a temporary period (i.e. as result of modifications/creations/deletions of lines), a registered handset shall 
always be attached to at least one line: the PP shall appear at least in one "Attached handset" field of one line setting. It 
may appear in several line settings if it is attached to several lines. 

Deleting an entry in the Internal Names List shall result in the de -registration of the corresponding handset from the 
system using the "Terminating access rights FT initiated" procedure. This procedure shall be performed as defined in 
EN 300 444 [12], clause 8.31. Additionally, the FP shall send a list change notification for the Internal Names List to all 
PPs (see clause 7.4.10.2.2).The "Attached handsets" field in the line setting(s) list shall also be automatically updated by 
the FP. If the corresponding handset is out of range when the 'delete entry' request is processed the FP shall delay the 
"Terminating access rights FT initiated" procedure until the PP goes back in range. The PP shall be however 
immediately removed from the Internal Names List and from the Attached handset' fields. 

Deleting one entry (one line) of the Line Settings List shall result in the de-attachment of the corresponding handsets 
from the line. If, as a consequence of a "delete entry" command on the Line Settings List, a handset is no longer 
attached to any line anymore, it shall however remain registered and available in the Internal Names List. This handset 
is no longer reachable from external lines. This temporary state may arise especially when removing and creating new 
lines. 

NOTE 1 : This mechanism makes it possible to register/unregister any handset to/from the DECT system, and to 
attach/detach it to/from a line in two separate steps. 

NOTE 2: As specified in the "Multiple lines" feature NG1.N.14, attachment may be PP-managed (for example, the 
user chooses the line at registration) or FP-managed (for example, the handset is attached by default to a 
line). 

A FP may decide not to implement the 'delete entry' and 'save entry' (for creating a new entry) commands for the Line 
Settings List. If the FP does not implement those commands it shall however answer those commands with negative 
acknowledgement reject reason 'procedure not allowed'. The PP shall support such answers. 

NOTE 3: This may be the case for a FP using a web interface to configure the line settings. Or for a FP supporting 
some PSTN lines (as the FP is designed by default with a given number of PSTN line connectors). 

NOTE 4: The 'save entry' command used for modifying an existing entry remains possible on FP side. 

If the "Base reset" influences the Internal Names List or the Line Settings List attached handsets, the corresponding 
handsets de-attachments and un-registrations shall be correctly handled. 
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7.4.1 1 .3 DECT System Settings List 

The following entry fields are defined for the (singular) DECT system list entry. 



Table 71 : Entry fields for the (singular) DECT system list entry 



Field 


Field 


Length 


Default 


Base reset 


Normative action/comment 


Clause 


identifier 




constraint 


value 
(note 1) 


impacted 






01H 


Current PIN code 


= 5 


YES/MD 


MD 


Before a PIN protected field 
(i.e.: a new PIN code) can be 
saved an edit/save of the 
current PIN code is required 


7.4.11.3.1 


02H 


Clock master 


= 2 


YES/MD 


MD 


Defines the entity which sets 
date an time for the DECT 
system (PP or FP) 


7.4.11.3.2 


03H 


Base reset 


= 2 


YES 


YES 


Sets settings back to default 
factory values 


7.4.11.3.3 


04H 


FP IP address / type 


= 1 


MD 


MD 


DHCP or static 


7.4.11.3.4 


05H 


FP IP address / value 


> 1 


MD 


MD 


Editable only for static IP 
address 


7.4.11.3.5 


06H 


FP IP address / 
subnet mask 


> 1 


MD 


MD 


Editable only for static IP 
address 


7.4.11.3.6 


07H 


FP IP address / 
gateway 


> 1 


MD 


MD 


Only for static IP address 


7.4.11.3.7 


08H 


FP IP address / DNS 
server 


> 1 


MD 


MD 


Only for static IP address 
'FP IP address / DNS server is 
a multiple instance field 


7.4.11.3.8 


09H 


FP version / Firmware 
version 


> 2, < 20 


YES/MD 


NO 


Software version of the FP 


7.4.11.3.9 


OAH 


FP version / Eeprom 
version 


> 1 , < 20 


MD 
(note 2) 


NO 


Eeprom version of the FP 


7.4.11.3.10 


OBH 


FP version / Hardware 
version 


> 2, < 20 


YES/MD 


NO 


Hardware version of the FP 


7.4.11.3.11 


OCH 


Emission mode 


>2 
(note 3) 


YES/MD 


MD 


Bitmap for 

activating/deactivating the 'No 
Emission mode', etc. 


7.4.11.3.12 


ODH 


New PIN code 


= 5 


YES/MD 


MD 


Allows modification of the PIN 
code 


7.4.11.3.13 


NOTE 1 : For optional or conditional fields, the default value only applies when the field is implemented 
NOTE 2: The field "Eeprom version" is mandatory but may be empty (length = 1 ) if the system does not use 
EEPROM. 


NOTE 3: 


-or the present revision of the present document, the length 


s always 2 (extensible field). 





Field identifiers from 0EH to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

Default value: it is the value of the setting when product is manufactured: 

• "YES" means that a default value is standardized. See corresponding setting clause definition. 

• "MD" means that a default value shall be provided by the manufacturer (could also be empty by setting the 
length to 1). 

• "YES/MD" means that a default value shall be provided by the manufacturer, which shall not be empty. 
"Base reset" impacted: describes the impact of the "Base reset" setting on this particular setting: 

• "YES" means setting is reset to default value when "Base reset" setting is activated. 

• "NO" means setting is not impacted by "Base reset" setting. 

• "MD" means manufacturer defines if the setting is impacted or not by the "Base reset" setting. 
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7.4.11.3.1 Field 'Current PIN code' 

The 'PIN code' field shall be coded as follows. 
Bits 



8 



6 



Field identifier = Current PIN code 



0/1 



0/1 



Editable 



Length (L) 



1 s ' byte 



^"byte 



^"byte 



j^byte 



Octet 
1 
2 
3 
4 



The 'Current PIN code' field shall respect the following rules: 
the PIN shall always have a length of 32 bits; 

each decimal digit entered by the user, is translated into one nibble (4 bits, BCD coded). The PT shall be 
capable to accept any PIN between and 8 decimal digits (limits included); 

the resulting string of nibbles is padded with as many leading 'F'H nibbles as necessary to achieve a total of 
8 nibbles; 

the result is a bitstring of 32 bits; 

on "Read Entry" or "Edit Entry" commands from the PP the FP shall always answer with the value 'FF'H 'FF'H 
'FF'H 'FF'H in order not to disclose the actual value of this field; 

on a "Save Entry" command from the PP, the FP shall not overwrite the stored value of the 'Current PIN code' 
field. This field is only used in order to compare the value submitted by the user with the stored value. As 
described in clause 7.4. 1 1 . 1 ('PIN code' section), the field value shall be changed by the FP when the field 
'New PIN code' field is successfully saved. 

EXAMPLE: A value of " 1091" (4 decimal digits entered via keypad) is translated into a bitstring pin code of 
the following value: 

"1111 1111 1111 1111 0001 0000 1001 0001", 

MSB: PIN[31] LSB: PIN[0] 

and coded as shown in figure 60: 

| FFH | FFH | 1 0H | 91 H | 

Figure 60: Example of PIN code coding 



7.4.11.3.2 Field 'Clock master' 

The 'Clock master' field shall be coded as follows. 
Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 






Field identifier 


= clock master 






1 


0/1 


Length (L 


) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


Value 


4 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'Clock master' 
field against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30H or 31H. 30H stands for FP, 31H stands for PP. 
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The behaviour of the PP and FP according to 'Clock master' field setting shall be consistent with the "Date and Time 
synchronization" feature described in clause 7.4.2. 

Bits 2 to 6 of octet 3 are reserved for further standardization and shall be set to "0". 

7.4.11.3.3 Field 'Base reset' 

The 'Base reset' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = base reset 


1 


0/1 


Length (L 


) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 


3 
















protected 




Value 


4 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'Base reset' field 
against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30Hor 31H. 30H stands for 'No', 31H stands for 'Yes'. 
The 'Base reset' field shall respect the following rules: 

• DECT system shall be initially delivered by the manufacturer with value 'Yes' (standard defined initial value). 

• If at least one DECT system setting, or line setting, has been set to a non default value, the 'Base reset' field 
shall be equal to 'No' when a PP performs a read command. 

• If a registered PP sets the value to Yes', after the save confirm command: 

All DECT system and line settings shall be reset to their default value in the FP. 

When the base reset is complete, the FP shall carry out the 'base reset' related requirements of 
clauses 7.4.1.3 ('Missed call notification') and 7.4.10.2 ('List change notification'). 

The setting shall remain set to Yes' until any DECT system or line setting is changed in the FP. 

Additionally, if the FP performs a software reboot: 

■ FP may send an 'end session' command on each LiA opened session; 

■ FP shall release all existing LiA calls in the system by sending a {CC-RELEASE} to the concerned 
PPs. 

PP shall support the possible reception of {CC-RELEASE} (for example linked to the reboot of the FP); 

If the FP does not perform a software reboot, all LiA sessions may remain opened until terminated by the 
PP. 

• Any attempt from a PP to set this parameter to 'No' shall result in a negative acknowledgement, with reject 
reason "procedure not allowed" from the FP (see clause 7.4.10.4.9). 

Default value: 31H(Yes ). 

Bits 2 to 6 of octet 3 are reserved for further standardization and shall be set to "0". 
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7.4.1 1 .3.4 Field "FP IP address / type' 

The IP address type' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 






Field identifier = 


IP address type 






0/1 


Length (L 


) 


0/1 


Editable 


DHCP 


Static 


X 


X 


X 


PIN 

protected 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP IP address / 
type' field against unauthorised modification, depending on its security policy. 

'DHCP' and 'Static' properties (bit 5 and 6 of octet 3). The IP address of the FP may be assigned dynamically using 
DHCP or manually using a static address entered by the user. The two property bits are exclusive (only one bit shall be 
set at a time). 

If the 'FP IP address / type' field is implemented in the FP, either 'DHCP' or 'Static' property shall be set to T (The PP 
cannot set both properties to '0'). 

Bits 2 to 4 of octet 3 are reserved for further standardization and shall be set to "0". 

7.4.1 1 .3.5 Field 'FP IP address / value' 

The IP address value' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = FP IP address / value 


1 


0/1 




.ength (L 


) 


2 


0/1 


Editable 


IPv4/6 


X 


X 


X 


X 


PIN 

protected 


3 


1 st 


oyte 


4 








2 nd 


byte 










3 ra byte 









Length octet (octet 2). The length of the field shall be set to 1' when the value of the field is not defined by the user. 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP IP address / 
type' field against unauthorised modification, depending on its security policy. 

'IPv4/6' property (bit 6 of octet 3). If set to 0, the format is IPv4 (4 bytes long); if set to 1, the format is IPv6 (16 bytes 
long). 

Address value (from octet 4): 

An IPv4 address shall always have a length of 4 bytes. 

EXAMPLE 1: A value of 192.168.213.1 is translated into an IP address / value' field with the following bytes: 
'C0A8D501'H. 

An IPv6 address shall always have a length of 16 bytes. 

EXAMPLE 2: A value of fdl 1 :2233:4455: 1 :a:b:c:d is translated into an IP address / value' field with the 
following bytes: 'FD1 1223344550001000A000B000C000D'H. 

Bits 2 to 5 of octet 3 are reserved for further standardization and shall be set to "0". 

7.4.1 1 .3.6 Field 'FP IP address / subnet mask' 

The IP address value' field shall be coded as follows. 



Bits 


8 


7 | 6 | 


5 ! 4 | 3 j 2 


1 


Octet 






Field identifier = 


FP IP address / subnet mask 




1 
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0/1 


1 


.ength (L 


) 


0/1 


Editable IPv4/6 x 


X 


x x PIN 

protected 


1 st 


oyte 


2™ byte 


3 ra byte 





Length octet (octet 2). The length of the field shall be set to T when the value of the field is not specified by the user. 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP IP address / 
subnet mask' field against unauthorised modification, depending on its security policy. 

'IPv4/6' property (bit 6 of octet 3). If set to 0, the format is IPv4 (4 bytes long), if set to 1, the format is IPv6 (16 bytes 
long). 

Subnet mask value (from octet 4): 

A subnet mask for IPv4 shall always have a length of 4 bytes. 

EXAMPLE 1: A value of 255.255.255.0 is translated into an IP address / subnet mask' field with the following 
bytes: 'FFFFFFOO'H. 

A subnet mask for IPv6 shall always have a length of 16 bytes. 

EXAMPLE 2: A subnet mask corresponding to a 59-bit prefix is translated into an IP address / subnet mask' field 
with the following bytes: 'FFFF FFFF FFFF FFE0 0000 0000 0000 0000'H. 

Bits 2 to 5 of octet 3 are reserved for further standardization and shall be set to "0". 

7.4.1 1 .3.7 Field 'FP IP address / gateway' 

The 'FP IP address / gateway' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = FP IP address / gateway' 


1 


0/1 


I 


.ength (L 


) 


2 


0/1 


Editable 


IPv4/6 


X 


X 


X 


X 


PIN 

protected 


3 


1 st 


Dyte 


4 








2™ 


byte 










3 ra byte 









Length octet (octet 2). The length of the field shall be set to '1' when the value of the field is not specified by the user. 

'PIN protected' property (bit 1 of octet 3). The PIN protected' property allows the FP to protect the 'FP IP address / 
gateway' field against unauthorised modification, depending on its security policy. 

'IPv4/6' property (bit 6 of octet 3). If set to 0, the format is IPv4 (4 bytes long), if set to 1, the format is IPv6 (16 bytes 
long). 

'FP IP address / gateway' value (from octet 4): The 'FP IP address / gateway' value shall always have a length of 
4 bytes (IPv4) or 16 bytes (IPv6). See the IP address / value' field for more information. 

Bits 2 to 5 of octet 3 are reserved for further standardization and shall be set to "0". 

7.4.1 1 .3.8 Field 'FP IP address / DNS server' 

The 'FP IP address / DNS server' field is a multiple-instance field (see clause 7.4.10.1, 'Field instances management' 
subsection) and therefore may be included several times in the entry: main server and alternate server(s). 
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The 'DNS server' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = FP IP address/ DNS server 


1 


0/1 


I 


.ength (L 


) 


2 


0/1 


Editable 


IPv4/6 


X 


X 


X 


X 


PIN 

protected 


3 


1 st 


Dyte 


4 








2™ 


byte 










3 ra byte 









Length octet (octet 2). The length of the field shall be set to T when the value of the field is not specified by the user. 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP IP address / 
DNS server' field against unauthorised modification, depending on its security policy. 

'IPv4/6' property (bit 6 of octet 3). If set to 0, the format is IPv4 (4 bytes long), if set to 1, the format is IPv6 (16 bytes 
long). 

'FP IP address / DNS server' value (from octet 4). The 'FP IP address / DNS server' value shall always have a length 
of 4 bytes (IPv4) or 16 bytes (IPv6). See the IP address / value' field for more information. 

Bits 2 to 5 of octet 3 are reserved for further standardization and shall be set to "0". 

7.4.1 1 .3.9 Field 'FP version / Firmware version' 

The 'firmware version' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 




Field identifier 


= FP version / Firmware version 




1 


0/1 


Length (L 


) 


2 


0/1 


X 


X 


X 


X 


X 


X 


PIN 

protected 


3 


1 st character byte 


4 


2™ character byte 


5 







'PIN protected' property (bit 1 of octet 3). The PIN protected' property allows the FP to protect the 'FP version / 
Firmware version' field against unauthorised modification, depending on its security policy. 

Characters shall be coded as defined for UTF-8 but restricted to the IA5 subset of characters (code point below or equal 
to 127). The length of this parameter (from octet 4) shall be of 20 octets maximum. 

Bits 2 to 7 of octet 3 are reserved for further standardization and shall be set to "0". 

7.4.1 1 .3.1 Field 'FP version / Eeprom version' 

The 'Eeprom version' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = FP version / Eeprom version 


1 


0/1 


Length (L 


) 


2 


0/1 


X 


X 


X 


X 


X 


X 


PIN 

protected 


3 


1 st character byte 


4 


2™ character byte 


5 







'PIN protected' property (bit 1 of octet 3). The PIN protected' property allows the FP to protect the 'FP version / 
Eeprom version' field against unauthorised modification, depending on its security policy. 
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Characters shall be coded as defined for UTF-8 but restricted to the IA5 subset of characters (code point below or equal 
to 127). The length of this parameter (from octet 4) shall be of 20 octets maximum. 

Bits 2 to 7 of octet 3 are reserved for further standardization and shall be set to "0". 

7.4.1 1 .3.1 1 Field 'FP version / Hardware version' field 

The 'Hardware version' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 




Field identifier 


= FP version / Hardware version 




1 


0/1 


Length (L 


) 


2 


0/1 


X 


X 


X 


X 


X 


X 


PIN 

protected 


3 


1 st character byte 


4 


2™ character byte 


5 







'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP version / 
Hardware version' field against unauthorised modification, depending on its security policy. 

Characters shall be coded as defined for UTF-8 but restricted to the IA5 subset of characters (code point below or equal 
to 127). The length of this parameter (from octet 4) shall be of 20 octets maximum. 

Bits 2 to 7 of octet 3 are reserved for further standardization and shall be set to "0". 

7.4.11.3.12 Field 'Emission mode' 

The 'Emission mode' field allows to activate or deactivate the 'No emission mode' feature on the FP from one of the 
PPs. It shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 





Field identifier = Emission mode 


1 


0/1 


Length (L 




2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


0/1 


reserved 


NEM 


4 



'PIN protected' property (bit 1 of octet 3). The PIN protected' property allows the FP to protect the 'Emission mode' 
field against unauthorised modification, depending on its security policy. 

Bits 2 to 6 of octet 3 are reserved for further standardization and shall be set to "0". 

Emission mode bitmap (octet 4): 

This field is a bitmap octet group. 

Bits 7 6 5 4 3 21 Meaning 

x x x x x x 'No emission mode' deactivated 

x x x x x x 1 'No emission mode' activated 

Bit 1: 'No emission' mode (NEM). If bit 1 is set, the FP shall activate the 'No emission mode' MAC service 
[NG1.M.5]. Otherwise the FP shall deactivate it. 

Bits 2 to 7 of octet 4 are reserved for further standardization and shall be set to "0". 
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7.4.11.3.13 Field 'New PIN code' 

The 'New PIN code' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 






Field identifier = 


= New PIN code 






1 


0/1 


I 


-ength (L) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 
= 1 


3 


1 st 


Dyte 


4 








2™ 


byte 










3 ra byte 




4 tn byte 





'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'New PIN code' 
field (hence the PIN) against unauthorised modification. For the field 'New PIN code', this property shall always be set 
toT. 

The 'New PIN code' field shall respect the following rules: 

• the PIN shall always have a length of 32 bits; 

• each decimal digit entered by the user, is translated into one nibble (4 bits, BCD coded). The PT shall be 
capable to accept any PIN between and 8 decimal digits (limits included); 

• the resulting string of nibbles is padded with as many leading 'F'H nibbles as necessary to achieve a total of 
8 nibbles; 

• the result is a bitstring of 32 bits; 

• on "Read Entry" or "Edit Entry" commands from the PP the FP shall always answer with the value FFH FFH 
FFH FFH in order not to disclose the actual value of this field; 

• the 'New PIN code' field shall only be modified via the "Save Entry" command if a successful "Save Entry" of 
the 'Current PIN code' field (see clause 7.4.11.3.1) has been executed before during the current call. See also 
clause 7.4. 1 1 . 1 for more information. After a successful save of the 'New PIN code' field, the value of the 
'Current PIN code' field shall also be changed to the same value. 

EXAMPLE: See example at clause 7.4. 11.3.1 and figure 60. 

Bits 2 to 6 of octet 3 are reserved for further standardization and shall be set to '0'. 
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7.4.1 1 .4 Line Settings List 

The following 'entry field identifier' for Line Settings List are defined. 



Table 72: Entry fields for a Line Settings List entry 



Field 
identifier 


Field 


Length 
constraint 


Default 
value 
(note 1) 


Base 
reset 
impacted 


Normative action/comment 


List change 
notification 
FP status 


Clause 


01H 


Line name 


> 2 


YES/MD 


MD 


Name of the line (cannot be 
empty) 


M 


7.4.11.4.1 


02H 


Line id 


>3 


YES/MD 


NO 


Line identifier 


M 


7.4.11.4.2 


03H 


Attached 
handsets 


> 2 


YES/MD 


MD 


List of registered handsets 
which are attached to the line 


M 


7.4.11.4.3 


04H 


Dialling prefix 


> 1 


MD 


MD 


If defined, adds a prefix to 
called party numbers for calls 
placed on the line 


O 


7.4.11.4.4 


05H 


FP melody 


> 1 


MD 


MD 


Melody of the FP linked to this 
line 


I 


7.4.11.4.5 


06H 


FP volume 


= 2 


YES/MD 


MD 


Melody volume of the FP 
linked to this line. 


I 


7.4.11.4.6 


07H 


Blocked 

telephone 

number 


> 1 


MD 


MD 


Forbidden called party 
numbers on the line. 'Blocked 
number' is a multiple instance 
field 





7.4.11.4.7 


08H 


Multiple calls 
mode 

(single/multiple) 


= 2 


YES/MD 


MD 


Current mode of the line: 
single call or multiple call 


M 


7.4.11.4.8 


09H 


Intrusion call 


= 2 


YES/MD 


MD 


Intrusion call allowed (YES / 
NO) 


C7201 


7.4.11.4.9 


OAH 


Permanent 
CLIR 


> 4 


YES/MD 
(note 3) 


MD 


Restrict number for all 
outgoing calls on this line 


M 


7.4.11.4.10 


OBH 


Call forwarding 
unconditional 


>5 


YES/MD 
(note 3) 


MD 


Stores the 

activation/deactivation codes 
and forwarding to number of 
the call forwarding 


M 


7.4.11.4.11 


OCH 


Call forwarding 
on No answer 


>6 


YES/MD 
(note 4) 


MD 


Stores the 

activation/deactivation codes, 
forwarding to number and 
number of seconds of the call 
forwarding 


M 


7.4.11.4.12 


ODH 


Call forwarding 
on Busy 
subscriber 


>5 


YES/MD 
(note 3) 


MD 


Stores the 

activation/deactivation codes 
and forwarding to number of 
the call forwarding 


M 


7.4.11.4.13 


C7201 : IF intrusion call feature NG1 .N.1 is implemented on FP side THEN M ELSE I. 


NOTE 1 
NOTE 2 
NOTE 3 
NOTE 4 


For optional or conditional fields, the default value only applies when the field is implemented. 
The empty setting for "FP melody" (length = 1) indicates use of a default melody. 

At least the 'Value' subfield shall have a value. Other fields may be empty (corresponding sub-length set to 0). 
At least the 'Value' and 'Number of seconds before call is forwarded' subfields shall have a value. Other fields 
may be empty (corresponding sub-length set to 0). A 'Number of seconds before call is forwarded' subfield set to 
'0' indicates use of FP defined default value. 



Field identifiers from 0EH to 80H are reserved for further standardization and shall not be used. 

Field identifiers from 81H to FFH are reserved for proprietary fields and may be freely used by implementers for coding 
of proprietary features. 

Default value: it is the value of the setting when product is manufactured: 

• "MD" means that a default value, if any, shall be provided by the manufacturer (could also be empty by setting 
the length to 1). 

• "YES/MD" means that a default value shall be provided by the manufacturer (shall not be empty). 

• "YES" means that a default value is standardized. See corresponding setting clause definition. 
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Base reset impacted: describes the impact of the "Base reset" setting on the given setting: 

• "YES" means that the setting is reset to default value when "Base reset" setting is activated. 

• "NO" means that the setting is not impacted by "Base reset" setting. 

• "MD" means "manufacturer defined", whether or not the setting is impacted by the "Base reset" setting. 
List change notification status: 

Sending a list change notification for line setting is mandatory when a setting is modified. However, for some fields that 
do not require the display of the PP to be aware, the notification is optional or irrelevant. See also clause 7.4.10.2.2. 

The list shall be sorted by ascending numerical order of the 'Line id' field values. 

Only one entry per line identifier shall exist in the Line Settings List. In other words, two distinct entries shall never 
have the same line id. If a PP attempts to add or modify an entry with an already existing line id in one entry of the list, 
the FP shall reject it with negative acknowledgement (see clause 7.4.10.4.9) / reject reason = 'content not accepted'. 

When the line name of a specific line is modified, the FP should automatically update the other lists where line name is 
stored (especially call lists). 

7.4.11.4.1 Field 'Line name' 

See Line name' field in "List access service" feature, clause 7.4.10.5.1.6. This field of the Line settings' list may be 
protected against unauthorised modification by the FP by use of the 'PIN protected' property (see clause 7.4.10.5.1.6). 

7.4.11.4.2 Field 'Line id' 

See Line id' field in "List access service" feature, clause 7.4.10.5.1.7. This field of the Line settings' list may be 
protected against unauthorised modification by the FP by use of the 'PIN protected' property (see clause 7.4.10.5.1.7). 

7.4.11 .4.3 Field 'Attached handsets' 

The 'Attached handsets' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 





Field identifier = Attached handsets 


1 


0/1 


Length (L 




2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


1 


Number of registered 


handsets attached to the line 


4 


0/1 


Handset bitmap 


5 


0/1 






1 


Handset bitmap (continued) 


5n 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'Attached 
handsets' field against unauthorised modification, depending on its security policy. 

Number of registered handsets attached to the line (octet 4): 

The number of handsets relates to the number of handsets attached to the line. The value shall be coded with the natural 
binary value, with the least significant bit in bit position "1". Allowable values are "1" to "127". 

Handset bitmap (octet group 5): 

This is a bitmap octet group, with the handset number 1 in bit position "1". A "1" indicates handset is attached to the 
line, and a "0" indicates it is not. 
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Handset bitmap (octet 5n) 



Bits 7 6 


5 


4321 


X X 


X 


X X X 1 


X X 


X 


X X 1 X 


X X 


X 


X 1 X X 


X X 


X 


1 X X X 


X X 


1 


X X X X 


X 1 


X 


X X X X 


1 X 


X 


X X X X 



Meaning 

Handset number 1 is attached 
Handset number 2 is attached 
Handset number 3 is attached 
Handset number 4 is attached 
Handset number 5 is attached 
Handset number 6 is attached 
Handset number 7 is attached 



NOTE 1: If the extension bit is "0" in the first octet (indicating presence of an additional octet), the least significant 
bit of second octet stands for handset number 8. 

NOTE 2: The format of the current field is a bit mask, it is different from the format of the number field of the 
Internal Names List (terminal id number) but represents the same handset numbers. 

Only the strictly necessary number of octets shall be transmitted over the air into the octet group depending directly on 
the number of registered handsets. It is not necessary to transmit the whole 19 octets of the octet group(covering the 127 
positions). 

EXAMPLE 1: If only handset number 1 and number 8 are attached to the line, the bitmap sent by the FP in 'read 
entries confirm' command or 'edit entry confirm' command contains only 2 octets. 

EXAMPLE 2: If handset number 8 de-attaches from the line with 'edit entry' and 'save entry' commands, the 
bitmap sent back by the PP in the 'save command' will contain only 1 octet. 

If no handset is attached to this line: 



• 'Number of handsets attached to the line' shall be set to 0. 

• No handset bitmap octet shall be included in the field. 



7.4.11.4.4 Field 'Dialling Prefix' 

See 'Number' field in "List access service" feature, clause 7.4.10.5.1.2. The field 'Dialling Prefix' may be protected 
against unauthorised modification by the FP by use of the 'PIN protected' property (see clause 7.4.10.5.1.2). 

The prefix shall be added by the FP to the called party number to any external outgoing call placed on the line. 

The length of the field shall be set to one when the value of the field is not defined. 



7.4.11.4.5 Field 'FP melody' 

See Associated melody' field in "List access service" feature, clause 7.4.10.5.1.12. The field 'FP melody' may be 
protected against unauthorised modification by the FP by use of the 'PIN protected' property (see clause 7.4.10.5.1.12). 

This field defines the melody to be used to ring in the FP on an incoming call on a dedicated line. 



7.4.11.4.6 Field 'FP volume' 

The 'FP volume' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = volume 


1 


0/1 


Length (L 


) 


2 


0/1 


editable 


X 


X 


X 


X 


X 


PIN 


3 
















protected 




Value 


4 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'FP volume' field 
against unauthorised modification, depending on its security policy. 
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'Value' octet (octet 4). The 'Value' octet shall be in the interval '30'H..'39'H. The '30'H value stands for the minimum 
adjustment of the volume level when the FP rings, and the '39'H value is the maximum adjustment. 

7.4.1 1 .4.7 Field 'Blocked number' 

See 'Number' field in "List access service" feature, clause 7.4.10.5.1.2, except that the possible value shall be in the 
interval '30'H..'39'H, plus the '2A'H value. The field 'Blocked number' may be protected against unauthorised 
modification by the FP by use of the 'PIN protected' property (see clause 7.4.10.5.1.2). 

The 'blocked number' field may be composed of: 

• either a single phone number value; or 

• a range of phone number values. In this case, the 'Number' field shall be equal to a sequence of one or more 
digit(s) followed by '*'. For example: "02*" represents all numbers starting with "02" digit sequence. 

When a PP attached to the line tries to place an external outgoing call on a number which is blocked, this call shall not 
be established by the FP. The FP shall release the call. 

This field may be contained several times in line settings entry (multiple instance field). This allows to block several 
numbers or ranges of numbers. See clauses 7.4.10.1 ("Field instances management") and 7.4.10.4.5 list access 'Save 
entry' command procedure for details how to handle several fields of the same type in the same entry. 

7.4.1 1 .4.8 Field 'Multiple calls mode' 

The 'Multiple calls mode' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 


Field identifier = Multiple calls mode 


1 


0/1 


Length (L 


) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 


3 
















protected 




Value 


4 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect the 'Multiple calls 
mode' field against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30H or 31H. 30H stands for "Single call mode", 31H for "Multiple call 
mode". 

This field is related to the "Multiple calls" feature (see clause 7.4.8) and allows to configure a multiple call line in single 
call mode. For non-multiple call lines, the value "Single call mode" shall always be used. 

7.4.11.4.9 Field 'Intrusion call' 

This field is related to the "intrusion call" feature (see clause 7.4.3.8). The 'intrusion call' field shall be coded as follows. 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 


Octet 






Field identifier 


= Intrusion call 






1 


0/1 


Length (L 


) 


2 


0/1 


Editable 


X 


X 


X 


X 


X 


PIN 

protected 


3 


Value 


4 



'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the Intrusion 
call' field against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30H or 31H. 30H stands for intrusion call (implicit or explicit) not 
allowed, 31H for intrusion call (implicit or explicit) allowed. 
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For "Implicit call intrusion" (see clause 7.4.3.8.1), the value also indicates the behaviour of the system when a call setup 
is attempted on the line (real call setup, versus call intrusion if the triggering conditions described in clause 7.4.3.8.1 are 
met). 



7.4.11.4.10 Field 'Permanent CLIR' 

The 'Permanent CLIR' field shall be coded as follows. 
Bits 



8 



0/1 



0/1 



Field identifier =Permanent CLIR 



Editable 



Length (L) 



Value 



CLIR activation code length 



CLIR activation code 1 s ' digit 



CLIR activation code 2 ng digit 



CLIR deactivation code length 



CLIR deactivation code 1 s ' digit 



CLIR deactivation code 2 ng digit 



PIN 

protected 



Octet 
1 

2 
3 

4 

5 

5a 



6 

6a 



'Length' octet (octet 2): the value of the length (L) indicator shall be > '4'. The field shall always contain at least the 
following octets: property bits octet, 'Value' octet, the ' CLIR activation code length ' octet and the 'CLIR deactivation 
code length'. 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 
'Permanent CLIR' field against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30H or 31H. 30H stands for CLIR de-activated for all calls, 31H for 
CLIR activated for all calls. 

Each digit shall be in the interval 30H..39H, and values 23H, 2 AH, 05H and 15H. 

If a PP sets or resets the value, the FP shall activate or deactivate the CLIR service in the network using the CLIR 
activation or deactivation code for all outgoing calls placed on the specified line. This setting shall be consistent with 
the CLIR feature [NG1.N.17]. 

If the PP supports the field (according to table 9, feature [NG1.N.16], supported line settings), the PP shall make at least 
the 'Value' accessible to the user. CLIR activation and deactivation codes may not be accessible to the user on the PP 
side. However the PP shall handle correctly those codes in the edit and save commands. (PP shall perform the save 
command with the same codes received in edit confirm). 

NOTE: This allows implementations where the codes can only be edited on FP side via a web interface for 
example. 

If no code is necessary to activate or deactivate the feature on network side for a specific line, the corresponding code 
length shall be set to zero. 

Default value: when the value of the field is not specified or no 'Permanent CLIR' is activated, the 'value' octet shall be 
set to '30H. The CLIR activation code length ' octet and the ' CLIR deactivation code length ' are set to '0' if the codes 
are not defined. Default CLIR codes are "manufacturer defined". 
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7.4.1 1 .4.1 1 Field 'Call forwarding unconditional' 

The 'Call forwarding' unconditional field shall be coded as follows. 
Bits 



8 



0/1 



0/1 



Field identifier =Call forwarding unconditional 



Editable 



Length (L) 



Value 



CFU activation code length 



CFU activation code 1 st digit 



CFU activation code 2 ng digit 



CFU deactivation code length 



CFU deactivation code 1 st digit 



CFU deactivation code 2™ digit 



Call forwarding number length 



1 st digit 



2^digit 



PIN 

protected 



Octet 
1 

2 
3 

4 
5 

5a 



6 

6a 



7 

7a 



Length octet (octet 2): the value of the length (L) indicator shall be > '5'. The field shall always contain at least the 
following octets: property bits octet, 'Value' octet, the 'CFU activation code Length' octet, the 'CFU deactivation code 
length' and the 'Call forwarding number length' octet. 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'Call 
forwarding unconditional' field against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30H or 31H. 30H stands for CFU de-activated for all calls, 31H for 
CFU activated for all calls. 



The digits represent the activation/deactivation codes and the call forwarding target number. Each digit shall be in the 
interval 30H..39H, and values 23H, 2AH, 05H and 15H. 

If a PP sets or resets the field, the FP shall activate or deactivate the corresponding Call forwarding in the network for 
specified type of calls received and on the specified line using the CFU activation code or CFU deactivation code. 

If no code is necessary to activate or deactivate the feature on network side for a specific line, the corresponding code 
length shall be set to zero. 

The PP shall make at least the 'Value' and the 'Call forwarding number' configurable by the user. CFU activation and 
deactivation codes may not be accessible to the user on the PP side. However the PP shall handle correctly those codes 
in the edit and save commands. (PP shall perform the save command with the same codes received in edit confirm). 

NOTE: This allows implementations where the codes can only be edited on FP side via a web interface for 
example. 

Default value: when the value of the field is not specified or no 'Call forwarding unconditional' is activated, the 'value' 
octet shall be set to '30H'. The 'CFU activation code Length' octet and the 'CFU deactivation code length' are set to '0' if 
the codes are not defined. The 'Call forwarding number length' octet is set to '0' if no number is defined. 

EXAMPLE: A PP may temporarily de-activate a call forward but keeping the codes and call forwarding 
number configured or "erasing" the last call forwarding number configured. 
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7.4.11.4.12 Field 'Call forwarding on No Answer' 

The 'Call forwarding on No Answer' field shall be coded as follows. 

Bit: |8|7|6|5|4|3 



0/1 



0/1 



Field identifier =Call forwarding on No Answer 



Editable 



Length (L) 



Value 



Nr of seconds before call is forwarded 



CFNA activation code length 



CFNA activation code 1 st digit 



CFNA activation code 2 w digit 



CFNA deactivation code length 



CFNA deactivation code 1 st digit 



CFNA deactivation code 2 digit 



Call forwarding number length 



1 s ' digit 



2^digit 



PIN 

protected 



Octet: 

1 

2 
3 

4 
5 

6 

6a 



7 

7a 



8 

8a 



Length octet (octet 2): the value of the length (L) indicator shall be > '6'. The field shall always contain at least the 
following octets: property bits octet, 'Value' octet, the 'Nr of seconds before call is forwarded' octet, the CFNA 
activation code length ' octet, the ' CFNA deactivation code length ' and the ' Call forwarding number length ' octet. 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'Call 
forwarding on No Answer' field against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30H or 31H. 30H stands for CFNA de-activated for all calls, 31H for 
CFNA activated for all calls. 



The digits represent the activation/deactivation codes and the call forwarding target number. Each digit shall be in the 
interval 30H..39H, and values 23H, 2 AH, 05H and 15H. 

The number of seconds before triggering the forwarding shall be coded with the natural binary value, with the least 
significant bit in bit position "1". Allowable values are "0" to "64". A value of zero indicates that the choice of the 
number of seconds is left to the FP (use of a default or preferred value configured in the FP). 

If a PP sets or resets the field, the FP shall activate or deactivate the Call forwarding on No Answer' in the network for 
specified type of calls received and on the specified line using the CFNA activation code or CFNA deactivation code. 

If no code is necessary to activate or deactivate the feature on network side for a specific line, the corresponding code 
length shall be set to zero. 

The PP shall make at least the 'Value' and the 'Call forwarding number' configurable by the user. Nr of seconds, CFNA 
activation and deactivation codes may not be accessible to the user on the PP side. However the PP shall handle 
correctly those codes in the edit and save commands. (PP shall perform the save command with the same codes 
received in edit confirm). 

NOTE: This allows implementations where the codes can only be edited on FP side via a web interface for 
example. 

Default value: when the value of the field is not specified or no 'Call forwarding on No Answer ' is activated, the 'value' 
octet shall be set to '30H. The 'CFNA activation code length' octet and the 'CFNA deactivation code length' are set to '0' 
if the codes are not defined. The 'Call forwarding number length' octet is set to '0' if no number is defined. 
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7.4.1 1 .4.1 3 Field 'Call forwarding on Busy subscriber' 

The 'Call forwarding on Busy subscriber' field shall be coded as follows: 

Bit: |8|7|6|5|4|3|2 



0/1 



0/1 



Field identifier =Call forwarding on Busy subscriber 



Editable 



Length (L) 



Value 



CFB activation code length 



CFB activation code 1 st digit 



CFB activation code 2 7g digit 



CFB deactivation code length 



CFB deactivation code 1 st digit 



CFB deactivation code 2 digit 



Call forwarding number length 



1 st digit 



2^digit 



PIN 

protected 



Octet: 

1 

2 
3 

4 

5 

5a 



6 

6a 



7 

7a 



Length octet (octet 2): the value of the length (L) indicator shall be > '5'. The field shall always contain at least the 
following octets: property bits octet, 'Value' octet, the 'CFB activation code length' octet, the ' CFB deactivation code 
length ' and the ' Call forwarding number length ' octet. 

'PIN protected' property (bit 1 of octet 3). The 'PIN protected' property allows the FP to protect (or not) the 'Call 
forwarding on Busy subscriber' field against unauthorised modification, depending on its security policy. 

'Value' octet (octet 4). The 'Value' octet shall be 30H or 31H. 30H stands for CFB de-activated for all calls, 31H for 
CFB activated for all calls.7 



The digits represent the activation/deactivation codes and the call forwarding target number. Each digit shall be in the 
interval 30H..39H, and values 23H, 2 AH, 05H and 15H. 

If a PP sets or resets the field, the FP shall activate or deactivate the Call forwarding on Busy subscriber' in the network 
for specified type of calls received and on the specified line using the CFB activation code or CFB deactivation code. 

If no code is necessary to activate or deactivate the feature on network side for a specific line, the corresponding code 
length shall be set to zero. 

The PP shall make at least the 'Value' and the 'Call forwarding number' configurable by the user. CFB activation and 
deactivation codes may not be accessible to the user on the PP side. However the PP shall handle correctly those codes 
in the edit and save commands. (PP shall perform the save command with the same codes received in edit confirm). 

NOTE: This allows implementations where the codes can only be edited on FP side via a web interface for 
example. 

Default value: when the value of the field is not specified or no 'Call forwarding on Busy subscriber' is activated, the 
'value' octet shall be set to '30H. The 'CFB activation code length' octet and the 'CFB deactivation code length ' are set 
to '0' if the codes are not defined. The 'Call forwarding number length' octet is set to '0' if no number is defined. 



7.4.1 1 .5 Virtual Contact List and Call List per Line 

The default behaviour of the "List access service" feature is to share all lists between all registered PPs, independently 
of the line attachments of the PPs. 

The current procedure allows to share virtually contact or call lists (Missed Calls List, Outgoing Calls List, Incoming 
Accepted Calls List, All Incoming Calls List and All Calls lists) only between handsets attached to the same line. For a 
system implementing this procedure, it shall be possible to switch back dynamically to the default behaviour. 



ETSI 



229 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



After reading or searching entries, the PP shall filter the entries that are related to a given line thanks to the line 
identifier field. This way, the PP has a possibility to show to the user only the calls and contacts that are related to one 
line (including the contacts that are attached to all lines). 

7.4.12 Calling line identity restriction (CLIR) 

7.4.12.1 Considerations 

The "Calling line identity restriction" feature defines procedures for CLIR as defined by 3GPP Technical specifications 
for Line identification supplementary services (see TS 122 081 [i.17]). 

This procedure allows a user to enable or to disable the presentation of its calling line identification when originating a 
call. When it is enabled, the originating network notifies the destination network that the calling party number is not 
allowed to be presented to the called party. If the called party subscribes to calling identification and the calling party 
has calling line identification restriction enabled, the called party shall receive the presentation indicator set to 
"presentation restricted" in the «CALLING-PARTY-NUMBER» IE of the {CC-SETUP}. In this case, the calling 
party's number will not be presented to the called party. 

The CLIR service may be provisioned in a permanent (for all outgoing calls) or a temporary mode (call by call basis). 

NOTE: It should be noted that this procedure allows to configure the network activation and deactivation codes 
from the PP. Nevertheless, these codes may be considered not being common end-user configurable but 
reserved for a well-informed user (and modified less often). For example call forwarding codes might be 
available through an advanced menu on PP side. Call forwarding activation may be available through 
other menus. 

7.4.1 2.2 Permanent CLIR mode (all calls) 

This procedure allows a user to enable or to disable the presentation of its calling line identification for all following 
outgoing calls for a specified line. 

When implementing the feature, the FP shall set bit a 30 of the "Extended higher layer capabilities (part 2)" (see 
EN 300 175-5 [5], clause F.3). 

To enable (respectively disable) the permanent CLIR mode, the user shall set (respectively reset) the 'Permanent CLIR' 
field of the specified line in the Line Settings List (see the "List access service" feature [NG1.N.16]). When this mode is 
enabled (respectively disabled), the FP shall invoke the permanent mode by sending the permanent CLIR activation 
(respectively deactivation) request to the network for the specified line. 

NOTE 1: The current procedure does not state anything about the availability or not of the service on Network side. 
PP1 

Permanent CLIR FP Network 

invocation on line u I 



line settings start session 



line u settings: 'Permanent CLIR' field set to '31 H' 



line settings end session 



Use of line u for sending 
a 'Permanent CLIR 
invocation' / 



Figure 61 : Permanent CLIR mode invocation 
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When the permanent mode is deactivated, it shall be always possible to use the temporary mode. 

NOTE 2: It should be noted that the permanent mode can also be provisioned by using the temporary mode for each 
call. 

7.4.1 2.3 Temporary CLIR mode (call by call) 

This procedure allows a user to disable the presentation of its calling line identification at the time of the call request. 

If the user requests a temporary CLIR mode when originating a call, the PP shall insert before the telephone number in 
the «MULTI-KEYPAD» IE the CLIR invocation temporary digits sequence. 



PP1 

Temporary CLIR 
invocation on line u 
+ 



FP 



Network 



if CC-SETUP is used: 



CC-SETUP 



=:< MULTI-KEYPAD, < Keypad info = 'CLIR invocation' > : > 



if CC-INFO is used: 



CC-SETUP 



« MULTI-KEYPAD, < Keypad info = 'called number' > >: 



CC-INFO 



CC-INFO 



Use of line u for calling 
'CLIR invocation + 
called number' 




Figure 62: Temporary CLIR mode invocation 

A temporary CLIR request shall override a permanent deactivated CLIR mode. 

NOTE 1 : It should be noted that the temporary mode can also be provisioned directly by the user by dialling the 
CLIR temporary digits sequence. 

NOTE 2: As the network temporary CLIR invocation digits sequence is network dependent, the sequence should be 
configurable on PP side. 

7.4.13 Call forwarding (external calls) 
7.4.13.1 Call forwarding common requirements 

The "Call Forwarding" feature defines procedures for Call Forwarding Unconditional (CFU), Calls Forwarding on No 
Answer (CFNA), and Calls Forwarding on Busy subscriber (CFB) as defined by 3GPP Technical specifications for Call 
Forwarding supplementary service Stage 1, 2 and 3 (see [i. 18], [i. 19] and [i.20]). 

The call forwarding service enables the user to request to forward all incoming external calls to another external number 
when some conditions are met. The FP shall relay the procedure activation and deactivation to the network. 

NOTE 1 : Depending on these conditions, the call may or may not be presented to the user before the forwarding 
occurs. 



NOTE 2: If the call is presented and the user picks up the presented call, forwarding of the call does not take place. 
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The "Call forwarding (external calls)" procedure uses the Call forwarding field of Line settings (see [NG1.N.16] List 
access service), i.e. the forwarding of calls applies to incoming calls on a specified line. When list change notification is 
supported by the FP, a notification shall be sent (see clause 7.4.10.2 List change notification) when 'Call forwarding' 
field is modified. 

NOTE 3: This may allow for example to display on handsets that calls are forwarded. 

NOTE 4: It should be noted that this procedure allows configuring the network activation and deactivation codes 
from the PP. Nevertheless, these codes may be considered not being common end-user configurable but 
reserved for a well-informed user. As a consequence, it is recommended not to edit them systematically 
on the PP side. For example these codes could be available in more "advanced" setting menu. 

The current procedure does not state anything about the availability nor the implementation of the service on Network 
side. It is considered by default that the operation is successful on Network side. 

Nevertheless, where a network negative confirmation is received following the call forwarding service request, the FP 
shall notify the PP that the service cannot be provided using a negative acknowledgement tone (see "tones provision" 
feature in clause 7.4.15). 

Call forwarding shall always be invoked for a specific line, not for all lines at the same time. Notifications shall also 
apply to the specified line (Value "All lines" for line identifier shall not be used in CALL INFORMATION IE). 

NOTE 5: Possible implementations on the Network side are not part of the current specification, please find some 
examples below just for information: 

EXAMPLE 1: Call forwarding invocation may be done by performing a speech call to a call forwarding platform 
with sending of the code at call setup. 

EXAMPLE 2: Negative confirmation, in the case of wrong code, may be done by a call rejection from network 
side. 

EXAMPLE 3: Result of the operation may be sent via audio inband information, in such a case, the list access 
session may end up in a speech session so that the user may hear the result of its call forwarding 
operation. 

7.4.13.2 External Call Forwarding Unconditional (CFU) to external number 

This procedure allows the user to forward all external incoming calls on a specified line to a given external number, 
without any triggering condition. 

To activate (respectively deactivate) the Call Forwarding Unconditional (CFU) mode, the user shall set (respectively 
reset) the 'Call forwarding unconditional' field of the specified line in the Line Settings List (see the "List access 
service" feature [NG1.N.16]) with the IA5 coded digits of the forwarded to telephone number. Network activation and 
deactivation codes are also saved as part of the field (although they might not be modified on PP side very often nor in 
the same menu). 

When this mode is activated (respectively deactivated), the FP shall invoke the call forwarding mode by sending the 
CFU activation (respectively deactivation) request to the network for the specified line. 
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PP1 

I 



FP 

_l_ 



Network 



Line settings start session 



Edit and save Line u settings: 'Call forward unconditional' 
field set to '31 'H + forwarded-to number (+network codes) 



Line settings end session 



If request accepted 



Activate CFU for 
line u 




FP notifies all PPs 
attached to this 



FACILITY 



«EVENTS NOTIFICATIONS, 
<List change indication, Line settings, N> > 
« CALL-INFORMATION, Lineld » 



If request rejected 
4 



CC-INFO 



« SIGNAL, '09'H » 




If required by the tone 
provision feature 

I 



Figure 63: CFU mode invocation 



7.4.13.3 External Call Forwarding on No Answer (CFNA) to external number 

This procedure allows the user to forward all external incoming calls on a specified line to a given external number, 
when the call is presented but not answered within a specified number of seconds. 

To activate (respectively deactivate) the Call Forwarding on No Answer (CFNA) mode, the user shall set (respectively 
reset) the 'Call forwarding on No Answer' field of the specified line in the Line Settings List (see the "List access 
service" feature [NG1.N.16]) with the IA5 coded digits of the forwarded to telephone number and the number of 
seconds. Network activation and deactivation codes are also saved as part of the field (although they might not be 
modified on PP side very often nor in the same menu). 

The number of seconds before triggering the forwarding shall be coded in binary value. A value of zero indicates that 
the choice of the number of seconds is left to the FP (use of a default or preferred value configured in the FP). 

When this mode is activated (respectively deactivated), the FP shall invoke the call forwarding mode by sending the 
CFNA activation (respectively deactivation) request to the network for the specified line. 
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PP1 



FP 



Network 



Line settings start session 



Line u settings: 'Call forward on No Answer' field set to 
'31 'H + nb of seconds + forwarded-to number 
(+ network codes) 



X 



Line settings end session 



If request accepted 



Activate CFNA for 
line u 





FP notifies all PP 
attached to the line 



FACILITY 



«EVENTS NOTIFICATIONS, 
<List change indication, Line settings, N> > 
« CALL-INFORMATION, Lineld » 



If request rejected 



CC-INFO 



If required by the tone 
provision feature 



Figure 64: CFNA mode invocation 



7.4.13.4 External Call Forwarding on Busy subscriber (CFB) to external number 

This procedure allows the user to forward all external incoming calls on a specified line to a given external number, 
when the line is busy. 

To activate (respectively deactivate) the Call Forwarding on Busy subscriber (CFB) mode, the user shall set 
(respectively reset) the 'Call forwarding on Busy subscriber' field of the specified line in the Line Settings List (see the 
"List access service" feature [NG1.N.16]) with the IA5 coded digits of the forwarded to telephone number. Network 
activation and deactivation codes are also saved as part of the field (although they might not be modified on PP side 
very often nor in the same menu). 

When this mode is activated (respectively deactivated), the FP shall invoke the call forwarding mode by sending the 
CFB activation (respectively deactivation) request to the network for the specified line. 
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PP1 

I 



FP 

_L 



Network 



Line settings start session 



Line u settings: 'Call forward on Busy subscriber' field set 
to '31 'H + forwarded-to number (+ network codes) 



Line settings end session 



If request accepted 



If request 



Activate CFB for 
line u 



FP notifies all PP 
attached to the line 



FACILITY 



«EVENTS NOTIFICATIONS, 
<List change indication, Line settings, N> > 
« CALL-INFORMATION, Lineld » 



ejected 



CC-INFO 



If required by the tone 
provision feature 



Figure 65: CFB mode invocation 



7.4.14 DTMF handling 



7.4.1 4.1 Uplink DTMF transmission 

The sending of Dual-Tone Multi-Frequencies (DTMF) to the network shall correspond to the sending of dialled digits 
on PP side at call setup or in active state (call connected). 

NOTE: For the additional support of variable length DTMF please refer to EN 300 444 (GAP) [12], clause 8.10, 
"Sending keypad information" and to clause D.2.2 of EN 300 175-5 [5]. 



7.4.14.1 .1 Uplink DTMF transmission at call setup when FP connected to classic switching 

network 

The system shall use DTMF mechanism at Network call setup, to transmit the called party number in a classic network 
switching circuit (use case on PSTN networks for example): 

• The PP shall send a «MULTI-KEYPAD» or «KEYPAD» information element to the FP that conveys 
dialled digits. 

• The PP shall not generate any in band audio DTMF. 

• The FP shall manage this keypad information correctly to send the DTMF to the network. The behaviour of 
the FP towards the network is described in clause D.l. 
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• For PSTN calls, the FP should mute the downlink audio stream sent toward the PP (in order to avoid echo). 

NOTE: The current procedure does not restrict the possible outgoing call methods. Using EN 300 444 [12], 

clause 8.3 "Overlap sending" procedure is one possible method among others in the present document. 



Hook Off 



PP 



FP 



Network 



CC-SETUP 


CALL SETUP 


► 

CC-SETUP-ACK 


< ► 

In band generation 
or 

out of band siqnallinq 
: ► 


«Codec List = Chosen codec» 
«Progress Indicator = Inband 
information» 

U-plane connected 
CC-INFO 


► 

«Multi-keypad = Dialled digits» 

CC-INFO 

^. 




«Multi-keypad = Dialled digits» 





7.4.14.1.2 



Figure 66: Using overlap sending and DTMF to establish a call 

Uplink DTMF transmission when connected 



The system shall be capable of sending DTMF to the network when call is established on network side in order to send 
some voice menu navigation commands. 

After a {CC-CONNECT} message: 

• The PP shall send a «MULTI-KEYPAD» or «KEYPAD» information element to the FP that conveys 
dialled digits. 

• The PP shall not generate any in band audio DTMF. 

• The FP shall manage this keypad information correctly to send the DTMF to the network. The behaviour of 
the FP towards the network is described in clause D.l. 



PP 



FP 



Network 







Call established 


CC-INFO 

»» 


In band generation 
or 

out of band siqnallinq 
: ► 


«Multi-keypad = Dialled digit» 
CC-INFO 




«Multi-keypad = Dialled digit» 





Figure 67: Sending DTMF when a call is established 
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7.4.14.2 Downlink DTMF reception 

The system shall be capable of receiving some Dual-Tone Multi-Frequency (DTMF) from the network. These DTMF 
shall correspond to the sending of dialled digits from the remote party. 

Upon reception of the DTMF from the network, there are two possible behaviours on FP side: 

• If DTMF are received in band from the network, the FP shall play transparently the DTMF as in band audio to 
the PP. 

• If DTMF are received out of band from the network, the FP may generate the DTMF as in-band audio in the 
active codec format. 

When connected to PSTN networks, the in-band generation method is used by the FP. 

If the FP is able to place calls on several lines from different networks that use different DTMF methods, the FP shall 
adapt the downlink DTMF transmission on a line by line basis. 

The format of in band DTMF is given in clause D.2. 



PP 




U-plane connected 



FP 



Network 




External Call 




If DTMF received in band 




In band DTMF in active 




In band DTMF 



If DTMF received out of band 2 



In band DTMF in active 



Out of band signalling 



Figure 68: Downlink DTMF reception possible cases 
7.4.1 4.3 Local DTMF feedback of dialled digits 

This procedure applies to a New Generation DECT system connected to an IP packet based network (like VoIP over the 
Internet) or connected to a PSTN network. It clarifies and simplifies the specific case where the system implements a 
local DTMF feedback in order to avoid non-interoperable or more complex implementations with echo in the FP. 

When a call is established on network side, when the user presses a digit key, it is recommended that the user gets a 
feedback to confirm that the key press was taken into account. Several implementations are allowed, this feedback may 
be: 

• a simple "bip"; 

• a local DTMF generation corresponding to the dialled digit; or 



• a visual indication of the digits. 

Especially for PP without display capabilities, it is recommended to generate the corresponding local DTMF instead of 
a simple "bip" generation for ergonomic reason. If such a mechanism is implemented in the system, the DTMF shall be 
generated locally by the PP and not by the FP. It is recommended that this DTMF generation respects also the 
guidelines given in clause D.3. 
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This echo of the DTMF shall remain local: 

• The recommended implementation is to mute temporarily the audio transmit path from the PP in order to avoid 
acoustic echo. 

• No additional DTMF in band sending from PP to FP shall be performed as it could interfere with 
procedure 7.4.14.1 Uplink DTMF transmission. 

• The FP shall not provide this feedback even for PSTN calls. 

NOTE: Please note that some mobile phone devices do not implement any DTMF generation (only visual 
feedback is used). 
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Figure 69: Local DTMF echo of dialled digits once call is established on network side 

The PP may additionally use the same mechanism in the following cases: 

1) When digit keys are pressed even if no SETUP is sent afterwards (case where you dial and then cancel the 
call). 

2) When digit keys are pressed before SETUP (pre-dialling method). 

3) When digit keys pressed after SETUP (post dialling method). See figure 66 for details. 



PP 



FP 



VoIP Network 



Hook off 




for each digit 



CC-SETUP 



CC-SETUP-ACK 



«Codec List = Chosen codec» 
«Progress Indicator = Inband 
information» 



U-plane connected 




CC-INFO 



«Multi-keypad = Dialled digits» 

CC-INFO 
«Multi-keypad = Dialled digits» 



CALL SETUP 



Out of band signaling 



Figure 70: Local DTMF echo of dialled digits after call setup 

For GAP PPs, the FP may optionally send an inband feedback of DTMF from FP to PP. 
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7.4.15 Tones provision 
7.4.15.1 General considerations 

The "Tones provision" feature describes the respective roles of the PP and the FP for tones provision to the user during 
an ongoing call. A tone may be related to the active call or to another call. 

NOTE: The provision of "ringtones" or melodies is out of the scope of the "Tones provision" feature. 

This feature is compatible with other features of the present document such as the "Multiple lines" [NG1.N.14] and 
"Multiple calls" [NG1.N. 15] features. 

Active call progress tones. It is recommended to provide tones indications while a call is in progress since silence may 
cause a user to believe that nothing is happening. In that respect, the "Tones provision" feature is intended to indicate to 
the user that the call is progressing, so as to prevent him from terminating the call prematurely. 

Some information is also given in annex E about tones format. 

As described in the following clauses, there are 3 exclusive methods (procedures) to provide tones on the NG-DECT 
system: 

• Method 1 - Tones provision by the system / IE «SIGN AL» method (NG-DECT Part 3 FP in front of 
NG-DECT Part 3 PP) as defined in clause 7.4.15.2.1. 

• Method 2- Tones provision by the system / in band method (NG-DECT Part 3 FP in front of GAP or 
NG-DECT Part 1 PP) as defined in clause 7.4.15.2.2. 

• Method 3- Transparency to tones provision by the network/PBX (in band tone generated by the network) as 
defined in clause 7.4.15.3. 

NG-DECT Part 3 PP: 

PP shall support all methods. The PP will receive an IE «SIGNAL» or an in-band tone and shall be able to 

play /generate the corresponding tone as far as required by table 73. From the PP point of view, method 2 and 3 are very 

close. 

NG-DECT Part 3 FP: 

For each tone, the FP shall use only one method toward a given PP to provide the tone. (For example dial tone and busy 
tones may be generated from the network, method 3, whereas negative acknowledgment tone is generated with 
method 1). 

Use of method 3 for a given tone depends on the network to which the FP it is connected to and does not depend on the 
PP type. 

Table 73 summarizes the tones scenarios for a NG-DECT Part 3 FP. 
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Table 73: Possible scenarios for a NG-DECT Part 3 FP regarding tones 
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Towards a NG-DECT Part 1 PP or 
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2 




External 


M 


1 
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M 
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(no Tones off needed) 
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Dial tone 


Internal 
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2 
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1 or 3 





2 or 3 


Off hook warning 


Internal 





1 
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tone 


External 





1 or 3 





2 or 3 


Network congestion 


External 





1 or 3 





2 or 3 


tone 













7.4.1 5.2 Tones provision by the system 

This procedure applies to internal call and to all external calls (first or parallel) when the network does not provide 
tones. As a consequence, tones shall be generated by the DECT system. 

However, in order to limit the complexity of the FP, a distinction is made between two cases: 

• NG-DECT Part 3 systems: NG-DECT Part 3 FP in front of a NG-DECT Part 3 PP. 

• Mixed systems: NG-DECT Part 3 FP in front of a GAP or NG-DECT Part 1 PP. 

7.4.1 5.2.1 Tones provision for a NG-DECT Part 3 FP in front of a NG-DECT Part 3 PP 

When an external or internal call is performed, the system shall provide the following tones to the user: 

• Ring-back tone. 

• Busy tone. 

• Call waiting tone (see clause 7.4.3.5.2). 

• Intercept tone (see clauses 7.4.16.2 and 7.4.3.8 (from FP to PP). 

• Negative acknowledgement tone (see clause 7.4.3.4). 

In addition, the system may provide the following tones to the user: 

• Dial tone. 

• Off-hook warning tone. 

• Network congestion tone (external calls only). 

As a consequence to this, the PP shall support at least the following IE «SIGNAL» values defined in 

EN 300 175-5 [5], clause 7.6.8: Ring-back tone on, Busy tone on, Call waiting tone on, Intercept tone on, Negative 

acknowledgement tone, Tones Off. 
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Additionally, it is recommended that the PP supports the following values: Dial tone on, Off-hook warning tone on, 
Network congestion tone on. This will increase the interoperability with a FP requesting these optional tones. 

The 'tone capability' field within the «Terminal capability» IE shall be correctly set in accordance to 

EN 300 175-5 [5]. However, no specific value is requested by the current procedure (as relying on the NG-DECT Part 3 

capability flag of the IE «Terminal capability» from the PP is sufficient for the FP implementation). 

For each one of the implemented tones listed above, on the basis of the signalling received from the network, the FP 
shall send IE «SIGNAL» in the correct CC messages to the PP to request a tone generation. 

Upon reception of these «SIGNAL» IEs, the PP shall generate the corresponding tone. It shall be generated in 
consistency with the active codec of the ongoing call. For stopping the tone generation, the PP shall respect the 
following: 

• For Intercept tone, negative acknowledgement tone and call waiting tone, the PP shall stop the generation by 
itself (as they are very short tones). 

• For all other tones, the tone shall be generated by the PP until reception of another tone request (e.g. Tones off 
or other tone) in any Call control message. 

Additionally, for the call waiting tone, the FP may re-send additional IE «SIGNAL» with 'call waiting tone on' value 
in order to repeat this short tone in the PP as long as the call waiting is presented by the FP to the PP. The PP shall 
generate the short call waiting tone at reception of each IE «SIGNAL». 

Figure 71 shows an example of external call where a NG PART3 PP generates tones. In this figure, the SIP protocol 
exchanges between the FP and the network shall be considered as an example and not as standardized exchanges. They 
are given here only to provide a better understanding of the tone feature. 
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Figure 71 : NG PART3 PP provides tones during SIP external call 



ETSI 



242 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



Figure 72 shows an example of internal call where a NG PART3 PP generates tones. In this figure, the SIP protocol 
exchanges between the FP and the Network shall be considered as an example and not as standardized exchanges. They 
are given here only to provide a better understanding of the tone feature. 
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Figure 72: NG PART3 PP provides tones during Internal call 

7.4.1 5.2.2 Tones provision for a NG-DECT Part 3 FP in front of a GAP or NG-DECT Part 1 
PP 

The aim of this procedure is to guarantee some minimum backward inter-operability with legacy PPs. 
When an external or internal call is performed, the system shall provide the following tones to the user: 

• Ring-back tone. 

• Busy tone. 
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In addition, the system may provide the following tones to the user: 

• Call waiting tone (see clause 7.4.3.5.2 "Call waiting indication"). 

• Intercept tone (see clause 7.4.16.2 "Headset call interception" and clause 7.4.3.8 "Call intrusion" (from FP to 
PP)). 

• Negative acknowledgement tone (see clause 7.4.3.4 Sending negative acknowledgement). 

• Dial tone. 

• Off-hook warning tone. 

• Network congestion tone (external calls only). 

For each of the implemented tone listed above, on the basis of the signalling received from the network, the FP shall 
generate the correct inland tone toward the PP. 

NOTE: It is preferable that the in-band tone is generated by the FP in the current active codec of the 

communication. However alternative implementation is also allowed. For example, the FP may switch or 
choose narrow band codec in order to "fall back" into narrow band before generating the tone. 

For each implemented tone, the FP shall not send any «SIGNAL» IE to the PP as this could lead to double 
generation effects (on FP plus PP sides). 

7.4.1 5.2.2.1 Indication of availability of in-band tones 

The FP shall indicate availability of in-band tones to the PP by connecting the U-plane, either: 

• by transmitting the «PROGRESS INDICATOR» information element indicating "in-band information or 
appropriate pattern now available" in an appropriate message (e.g. {CC-SETUP-ACK}, { CC- ALERTING } , 
{CC-CALL-PROC}...); 

• by sending the {CC-CONNECT} message. 

NOTE 1 : The selected codec will be confirmed at the latest in the same message. 

NOTE 2: The FP should avoid sending the «PROGRESS INDICATOR» information element in a {CC-INFO}, 
either by opening the U-plane early in call setup stages or by using {CC-CONNECT}. In effect, the 
support of «PROGRESS INDICATOR» is not defined as mandatory for {CC-INFO} on PP side in 
EN 300 444 (GAP) [12] nor in TS 102 527-1 [21]. 

NOTE 3: The current procedure does not strictly mandate the sending of «PROGRESS INDICATOR» from FP 
as there are two methods for connecting the U plane. This is also consistent with the optional status of 
«PROGRESS INDICATOR» sending from FP in EN 300 444 (GAP) [12] and in TS 102 527-1 [21]. 

The PP shall accept these in-band tones in the active codec and therefore not replace them with locally generated tones 
(if available). 
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Figure 73 shows an example where the FP indicates the availability of call progress tones to the PP using the 
«PROGRESS INDICATOR» information element. In this figure, the SIP protocol exchanges between the FP and the 
Network shall be considered as an example and not as standardized exchanges. They are given here only to provide a 
better understanding of the "Tones provision" feature. 
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< < Progress Indicator^ Inband information » 
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-< 
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► 
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BYE 


s ; \ ' Generate off-hook warning tone ! 





CC-RELEASE 
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CC-RELEASE-COM 






Figure 73: FP provides tones during external call using progress indicator 
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Figure 74 shows an example where the FP indicates the availability of call progress tones to the PP using the 
{CC-CONNECT} message. In this figure, the SIP protocol exchanges between the FP and the Network shall be 
considered as an example and not as standardized exchanges. They are given here only to provide a better 
understanding of the "Tones provision" feature. 
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Figure 74: FP provides tones during external call using {CC-CONNECT} 
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Figure 75 shows an internal call example where the FP indicates the availability of call progress tones to the PP using 
the « PROGRESS INDICATOR» information element. In this figure, the SIP protocol exchanges between the FP 
and the Network shall be considered as an example and not as standardized exchanges. They are given here only to 
provide a better understanding of the "Tones provision" feature. 
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Figure 75: FP provides tones during Internal call using progress indicator 
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Figure 76 shows an internal call example where the FP indicates the provision of call progress tones to the PP using the 
{CC-CONNECT} message. 
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Figure 76: FP provides tones during Internal call using {CC-CONNECT} 
7.4.1 5.3 Transparency to tones provision by the network or PABX 

This procedure applies to a FP when a call is placed on a network or PABX that provides in-band tones (e.g. PSTN, 
private network or PABX). 

When the FP recognizes the used network or PABX as a network providing in-band tones, the FP shall not generate 
in-band tones or request PP tone generation. 

The FP shall indicate availability of in-band tones to the PP by connecting the U-plane. Connection of U-plane 
is described in clause 7.4.15.2.2.1. 

The FP shall transparently play network or PABX originating audio in-band tones toward the PP in the U-plane. 



ETSI 



248 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



Figure 77 shows an example where external call is placed on a Network which provides tones. In this figure, the 
protocol exchanges between the FP and the Network shall be considered as example and not as standardized exchanges. 
They are given here only to provide a better understanding of the "Tones provision" feature. 
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Figure 77: Network provides tones during PSTN external call 



7.4.16 Headset management 



7.4.16.1 



Headset considerations 



The "Headset management" feature defines a set of procedures that allow a better support of wideband headset PPs 
within an NG DECT system. This feature has been designed to guarantee a minimum of interoperability of NG DECT 
Part 3 systems with NG DECT Part 3 headsets without defining a complete new headset profile, while impacting only 
slightly the NG DECT PART3 FP implementation. 

This feature simplifies the use of headsets for customers while remaining compatible with the basic and extended 
telephony features defined in the present document (call transfer, call intrusion, parallel calls, etc.). See clause 7.4.16.8 
for compatibility details. 

When implementing the "Headset management" feature, the HPP shall set the corresponding terminal capability bit: 
"Support of the Headset management feature". 

For subscription registration, an HPP shall use the "0000" pin code value, as there is no numeric keypad on the HPP. 
The HPP should also follow as much as possible the "Registration mode automatic access" procedure (see 
clause 7.10.1.3.1), and also the "Searching mode request" procedure (see clause 7.10.1.2.3), with the restriction that no 
keypad shall be used. 
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NOTE: The user may change the PIN code of his/her system at any time and from any PP. But the PIN code will 
have to be set to default 0000 value at least temporarily for the HPP registration procedure to be 
successful. 

For the following procedures, a headset PP may interact with any registered standard PP of the DECT system. 

7.4.1 6.2 Headset call interception 

This procedure allows to dial an outgoing call on a handset and to continue with the call on a headset. But this 
procedure also applies when a PP is involved in a call to switch the call to the headset PP. 

7.4.1 6.2.1 Initiation of the call 

The outgoing call shall be initiated from any of the registered PPs using the PP keypad. The HPP shall then initiate the 
call interception procedure, as defined in clause 7.4.16.2.2. 

An HPP should always initiate outgoing calls using a 'call interception request', except in the following specific use 
cases: 

• redial of the last outgoing call (see clause 7.4.16.4); 

• redial of the last incoming call (see clause 7.4.16.5). 

7.4.16.2.2 Call interception 

This procedure mainly applies to an HPP willing to replace a PP involved in an existing ongoing call. The replaced PP 
may be attached to the same line or not. 

NOTE 1: The "Call interception" procedure also applies in the following two cases: 

■ a standard PP tries to intercept a call of another PP; 

■ a standard PP tries to intercept a call of an HPP. 

In these cases, it is necessary to replace the term "PP" with "HPP and/or "HPP" with "PP", as appropriate 
in the following text of the clause so that it remains applicable. 

NOTE 2: "Call interception" is another way to carry out a call transfer in which the transfer is triggered from the 
targeted PP. 

The call interception shall be considered as successful if the following two conditions are met: 

• Condition 1: There is a single active call (on one PP) in the system (this call shall already be in call 
proceeding, call alerting or connected state). 

• Condition 2: Call interception is allowed on this PP. In other words, the value of the 'Call interception' 
parameter in the Internal Names List is set to 'Allowed' for this PP. 

When a PP is involved in a call, an HPP willing to intercept this call in order to be connected with the remote party 
instead of the PP, shall attempt to place a call with a {CC-SETUP}: 

• using the 'Normal call setup' basic service; 

• together with the "Call interception request" control code '1C50 2A'H transmitted in a «MULTI-KEYPAD» 
information element in the {CC-SETUP} message (see clause 7.4.3.2). 

Successful case: if the two conditions for successful call interception above are met, the DECT system behaviour shall 
be the following: 

• The intercepted call between the HPP and the remote party is considered as a standard internal or external call. 
The 'call identifier' assigned by the FP for this call shall be the 'call identifier' for the intercepted call. 
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• As soon as the control code is received, the FP shall answer the HPP: 

for a non-early {CC-CONNECT} implementation, with a {CC-CALL PROC} message, including a 
«CALL INFORMATION» IE containing: 

■ the call id of the intercepted call; 

■ the call status "CS call proc"; 

■ if the intercepted call is external, the line id, together with the 'line type information' shall be sent 
either in the {CC-CALL-PROC}, or in a subsequent {CC-INFO} without any call status sent 
before {CC-CONNECT}. 

for an early {CC-CONNECT} implementation, with a {CC-CONNECT} message, including a «CALL 
INFORMATION» IE containing: 

■ the call id of the intercepted call; 
followed by a {CC-INFO} message containing: 

■ the call id of the intercepted call; 

■ the call status 'CS call proc'; 

■ if the intercepted call is external, the line id, together with the 'line type information', shall be sent 
either in the {CC-CONNECT}, or together with the 'CS call proc' call status, or in a subsequent 
{CC-INFO} without any call status sent before 'CS call connect'. 

• Standard codec negotiation mechanisms shall apply between FP and HPP. The FP shall select the codec used 
between FP and HPP together with the 'CS call connect' call status at the latest. 

• The FP shall notify the PP of the call interception with a {CC-INFO} message containing: 

the HPP CLIP («CALLING PARTY NUMBER» IE); 

the «CALL INFORMATION» IE with the call status 'CS call intercepted' and the same call identifier 
(call identifier of the intercepted call); 

if required by the "Tones provision" feature (see clause 7.4.15.2), the information element «SIGNAL» 
with the value 02H indicating Intercept tone on'. 

• The FP shall wait at least a duration of <CC.NG.01> before releasing the call between the FP and the PP with 
a {CC-RELEASE} message. During this period, the FP shall "ignore" the audio received from the PP. 

• If the intercepted call is established (cf. condition 1 above) the FP shall connect the HPP: 

for a non-early {CC-CONNECT} implementation, with a {CC-CONNECT} message, including a 
«CALL INFORMATION» IE containing: 

■ the call id of the intercepted call; 

■ the call status 'CS call connect'; 

for an early {CC-CONNECT} implementation, with a {CC-INFO} message, including a «CALL 
INFORMATION» IE containing the same information. 

NOTE 3: If the intercepted call is not yet established with PP1, the FP adapts its behaviour towards the HPP 
accordingly, i.e. for a non-early CC-CONNECT implementation, the FP sends nothing (CALL 
PROCEEDING state already reached), or sends {CC-ALERTING}. 

NOTE 4: Upon reception of the 'CS call intercepted' call status, the PP may warn the user that the call was 
intercepted (displaying a message, etc.). 

• The FP shall connect the U-plane between the FP and HPP. The peer-to-peer audio path from the remote party 
shall be routed to HPP (instead of PP). 

An example of a successful call interception is given in figure 78. 
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Figure 78: Successful call interception 

NOTE 5: The Call Control message sequence in figure 78 should be understood as an example. The real sequence 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 6: The call interception mechanism may be considered as an automatic call transfer requested by HPP and 
performed by the FP. 
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Call interception failure cases: The following cases are distinguished and differ mainly by the tone issued in each case 
by the FP to properly warn the HPP user: 

Case 1. If the call interception request from the HPP occurs when there is no initiated call on any PP of the DECT 

system: 

• The FP shall consider the request as a standard outgoing call request, and shall issue: 

for a non-early {CC-CONNECT} implementation, a {CC-SETUP_ACK}message; 

for an early { CC-CONNECT } implementation, a { CC-CONNECT } message, followed by a { CC-INFO } 
message, including a «CALL INFORMATION» IE with 'CS call setup ack' call status. 

If the FP implements a dial tone as described in "Tones provision" feature (see clause 7.4.15.2) the FP may 
send additionally a dial tone (sending of the appropriate IE «SIGNAL» in a {CC-INFO}). This warns the 
user that the line is available. Please note this call has few chances to be established as the HPP is very 
unlikely to send the missing digits. 

• The HPP shall finally release the call with {CC-RELEASE} message (For example upon user hang-up 
request). 

Case 2. If the call interception request from the HPP occurs "too early", before all necessary digits were entered by the 
PP to correctly establish the call with the remote party: 

• The FP, PP and HPP shall however proceed to the call interception as described in the successful case above. 

• The FP should then behave toward the HPP as for a standard PP call when not enough digits are entered. (For 
example by issuing the dial tone and a busy tone after a certain time). Please note this call has few chances to 
be established as the HPP is very unlikely to send the missing digits. 

• The HPP shall finally release the call with {CC-RELEASE} message. For example upon user hang-up request. 

Case 3. If the call interception request occurs and the 'Call interception' parameter is set to 'Not allowed' in the Internal 
Names List: 

• As soon as the control code is received, the FP shall answer the HPP: 

for a non-early {CC-CONNECT} implementation, with a {CC-CALL PROC} message, including a 
«CALL INFORMATION» IE containing: 

■ the call id of the intercepted call; 

■ the call status 'CS call proc'. 

If the intercepted call is external, presence or not of the line id is left free to the implementer. If present, 
the line id, together with the 'line type information' shall be sent either in the {CC-CALL-PROC}, or in a 
subsequent {CC-INFO} without any call status sent before call status 'CS call disconnecting' (see 
below): 

for an early {CC-CONNECT} implementation, with a {CC-CONNECT} message, including a 
«CALL INFORMATION» IE containing: 

the call id of the intercepted call; 

followed by a {CC-INFO} message containing: 

the call id of the intercepted call; 

the call status 'CS call proc'. 

If the intercepted call is external, presence or not of the line id is left free to the implementer. If present, 
the line id, together with the 'line type information', shall be sent either in the {CC-CONNECT}, or 
together with the 'CS call proc' call status, or in a subsequent {CC-INFO} without any call status sent 
before 'CS call disconnecting' (see below). 
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• The FP shall then use the "Busy system or line notification" procedure of clause 7.4.8.3, that is: 

the FP shall send call status 'CS call disconnecting' along with call status reason 'control code failed'; 

the FP shall send a «CALL INFORMATION» IE with call status 'CS idle' in order to free the call id 
(on the HPP side only). 

• The HPP shall finally release the call with {CC-RELEASE} message (for example upon user hang-up 
request). 

NOTE 7: The call identifier of the intercepted call is used as in the successful case although in this case the call 
interception fails. 

Specific case with multiple calls or multiples lines feature. 

If the FP implements multiple calls or multiples lines features and a call interception request from the HPP occurs when 
there is more than one active outgoing calls in the DECT system, the behaviour of the system shall be the following: 

• The FP shall issue a «DISPLAY» message toward the PPs in communications, notifying the user that a call 
interception is requested by the HPP. The sending of the DISPLAY may be restricted to only the PPs attached 
to the same line(s) as the HPP. 

• The first PP to send a "#" keypad will be considered as the intercepted party. This shall be done by the PP by 
sending a control code 23H in a «MULTI-KEYPAD» information element within a {CC-INFO} message. 

• Only upon reception of this keypad, the FP shall then proceed to the call interception of the active call with 
this specific PP as in the successful case. (The call shall be released on PP with prior intercept tone and 
switched to HPP). 

NOTE 8: The '#' keypad sending remains compatible with GAP handsets. 

NOTE 9: The HPP may release the call at any time. This is also the way to terminate this specific case if none of 
the PP sent the "#" keypad (no need for specific timer in the FP to handle this case). 

NOTE 10: The FP may additionally support alternative keypad values with equivalent behaviour to "#". (This allows 
an alternative implementation to prevent the very specific case where a second PP accepts the call 
interception after a first one already accepted, and where the "#" keypad would be transmitted over the 
network as standard keypad/DTMF with unexpected effect in the network). 

Interception of internal calls: 

The FP may support interception of internal calls additionally to interception of external calls. This shall be based on 
the same "#" keypad mechanisms as described in the multiple calls/multiple lines clause above. The first PP which 
invokes the "#" keypad will be considered as the intercepted party. 

7.4.1 6.3 Headset incoming call 

When receiving an incoming call (external or internal) in the DECT system, the HPP may answer this call using the 
usual incoming call procedures. 

The HPP behaves as a standard PP toward the FP in the DECT system in this case. 

7.4.1 6.4 Re-dial of last outgoing call 

This procedure applies to the HPP and the FP only. 

Upon user request on HPP for re -dialling the last outgoing call: 

• The HPP shall attempt to place a call with a {CC-SETUP} using the 'Normal call setup' basic service. The 
HPP shall not invoke the "Call interception" procedure. 

• The HPP shall access the last entry of the 'outgoing call' list of the FP to retrieve the number of the last 
outgoing call (see 'List access' feature in clause 7.4.10 and annex C for guidelines). 
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• If the 'outgoing call' list is available in the FP: 

The HPP shall use this number to fill the «MULTI-KEYPAD» information element sent in a 
{CC-INFO} message. 

The FP shall establish the outgoing call using this number. 

• If the 'outgoing call' list is not available in the FP: 

The FP shall issue a start session confirm with a <Start session reject reason> equal to 'list not supported'. 
The HPP may play a negative acknowledgment tone. 

• The HPP shall finally release the call with a {CC-RELEASE} message. For example upon user hang-up 
request. 

NOTE: Re -dialling the last outgoing call is also possible from any registered handset. The HPP may then use the 
regular outgoing call procedure defined in clause 7.4.16.2 and intercept the call. 

If the call cannot be established with the network on the FP side for resources reasons (no line available for example) 
the FP shall notify the HPP with a busy tone as defined in the "Tones provision" feature (see clause 7.4.15.2). 

7.4.1 6.5 Re-dial of last incoming call 

The HPP shall store the CLIP of the last incoming external call. 

Upon user request on HPP for re-dialling the last incoming call, the HPP shall re -use the number included in the CLIP 
of the last incoming external call. 

• The HPP shall attempt to place a call with a {CC-SETUP} using the 'Normal call setup' basic service. The 
HPP shall not invoke the "Call interception" procedure. 

• HPP shall use this number to fill a «MULTI-KEYPAD» information element sent in a { CC-INFO } 

message. 

• The FP shall establish the outgoing call using this number. 

If the call cannot be established for resources reasons (FP or network reasons) the FP shall notify with a busy tone 
toward the HPP as defined in "Tones provision" feature (see clause 7.4.15.2), using the appropriate «SIGNAL» 
information element. 

7.4.1 6.6 Switching from headset to handset (headset initiated) 

This procedure applies to the FP, the HPP involved in an active call, and any registered PP. It consists in transferring 
the call from the HPP to the PP. 

The HPP shall invoke the call transfer procedure (see clause 7.4.3.6) and more specifically the unannounced call 
transfer procedure (see clause 7.4.3.6.2). 

FP shall support both possible unannounced call transfer requests from HPP: 

• Transfer by calling all PPs: using 2AH as terminal identity number for the internal call. 

• Transfer by calling one selected PP: using the corresponding terminal identity number for the internal call. 

7.4.1 6.7 Switching from headset to handset (handset initiated) 

This procedure applies to the FP, a HPP involved in an active call and any registered PP. It assumes a call interception 
request can be initiated from the PP via a dedicated MMI. 

The switching is triggered by a user request on the PP. The PP shall invoke the call interception procedure (see 
clause 7.4.16.2.2). 

The call initially active on HPP is "switched" to the intercepting PP. 



ETSI 



255 ETSI TS 1 02 527-3 V1 .5.1 (201 3-03) 

7.4.1 6.8 Compatibility with other telephony features and profiles 

Clause 7.4.16.8.1 clarifies the behaviour and limitations of the HPP regarding other features of the present document, 
taking into account that an HPP is considered as a standard PP with however a very limited set of keys. 

7.4.1 6.8.1 Compatibility with other telephony features for a headset portable part (HPP) 

When an HPP is registered on a FP, all the features of the present document apply by default for both parts with status 
defined in clauses 6.2 and 6.4. However, the following restrictions or clarifications also apply: 

Compatibility with Easy PIN code registration [NG1.A.1]: 

This feature is not applicable to HPP except if HPP has keyboard. 
Compatibility with Easy pairing registration [NG1.A.2]: 
This feature is not applicable to HPP except if HPP has keyboard. 
Compatibility with Missed call notification [NG1.N.3]: 

All procedures are applied on FP side toward the HPP as for a standard PP (sending of notifications). 
The HPP may support the feature. 

Compatibility with Voice message waiting notification [NG1.N.4]: 

All procedures are applied on FP side toward the HPP as for a standard PP (sending of notifications). 
The HPP may support the feature. 

Compatibility with Date and time synchronization [NG1.N.5]: 

All procedures are applied on FP side toward the HPP as for a standard PP (sending of time/date). 
The HPP may support the feature but it is very unlikely. 

Compatibility with Parallel calls [NG1.N.6] and Common parallel call procedures (external or internal) 
[NG1.N.7]: 

All procedures are applied on FP side toward the HPP as for a standard PP (sending of notifications). 

It is recommended that the HPP supports at least "Active call release with replacement (from PP to FP)" of 
clause 7.4.3.5.12. The HPP may support the other procedures but this is unlikely. 

Compatibility with Call transfer (internal or external) [NG1.N.8]: 

The HPP may support the feature. See also procedure "Switching headset to handset (headset initiated)", 
clause 7.4.16.7. 

Compatibility with 3-party conference call (internal or external) [NG1.N.9]: 

The HPP may participate into a conference call but support of the feature is unlikely (complex to initiate a conference 
from the HPP). 

Compatibility with Intrusion call [NG1.N.10]: 

The HPP may support implicit or explicit call intrusion. 
Compatibility with Line identification [NG1.N.12]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 
The HPP shall support the feature for performing regular calls. 

EXAMPLE: When performing a "regular" external outgoing call, the HPP shall use a line identifier. 
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However, when performing a call interception, the HPP shall not send any line identifier value, nor the 'None' line 
identifier value (see clause 7.4.16.2.2). 

Compatibility with Call identification [NG1.N.13]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 
A HPP shall implement the feature. 
Compatibility with Multiple lines [NG1.N.14]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 

A HPP may implement the feature. The HPP is considered as a standard PP regarding attachment to lines in the Line 
Settings List. 

Compatibility with Multiple calls [NG1.N.15]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 

A HPP may implement the feature. 

Compatibility with List access service [NG1.N.16]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 

A HPP may implement the feature and access any of the lists available in the FP. 

Compatibility with the DTMF handling feature [NG1.N.19]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 

DTMF feature from HPP is unlikely but may be possible if HPP has keyboard. 

Compatibility with Tones provision feature [NG1.N.20]: 

All procedures shall be applied on FP side towards the HPP as for a standard PP. 

Compatibility with Handling of lines where second calls are signalled in-band feature [NG1.N.22]: 

All procedures shall be applied on FP side towards the HPP as for a standard PP (sending of notifications). 

It is recommended that the HPP supports at least "Active call release with replacement (from PP to FP)" of 
clause 7.4.3.5.12. The HPP may support the other procedures but this is unlikely. 

Compatibility with Dialled digits (basic) [GAP.N.4]: 

HPP may implement the feature (e.g. shortcut key to request re -dial of last outgoing call or last incoming call). 
Compatibility with internal call feature [GAP.N.31]: 

All procedures are applied on FP side toward the HPP as for a standard PP. 
A HPP may implement the feature and place internal calls. 

7.4.1 6.8.2 Compatibility of a NG-DECT Part 3 headset portable part with other profiles 
Behaviour of NG-DECT Part 3 headset registered on a GAP or NG-DECT Part 1 FP: 

• It shall be possible to answer HPP incoming calls as the HPP behaves as a standard PP for incoming call. 

• For outgoing calls possible behaviour of the FP may be the following: 

If the FP supports a "headset management" equivalent feature, the HPP may use it as described in the 
present document. 

If the FP supports a "Call intrusion" equivalent feature, the HPP may intrude an outgoing call, if any PP 
is already involved in a call, FP will handle the call intrusion between PP and HPP. 
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If internal call transfer is supported by the FP, call will have to be established on PP first and then 
transferred to the HPP. 

If none of the above features are supported, placing an outgoing call with HPP is not described. 

• With GAP FP, established calls will only be narrow band calls. 

Behaviour of NG-DECT Part 3 headset registered on a NG-DECT Part 3 FP with a GAP or NG-DECT Part 1 
registered PP: 

The current "headset management" feature applies with the following restrictions: 

• The intercept tone shall be sent in band from FP to PP during outgoing call (instead of out band), (see the 
"Tones provision" procedure in clause 7.4.15.2.2). 

• If the HPP intercepts the call of a GAP PP, the intercepted call (originally in G.726 with GAP PP) may be 
re-negotiated to another codec between FP and HPP (G.722 for example). 

7.4.17 UTF-8 CNIP 

7.4.1 7.1 UTF-8 CNIP sending from the FP to PP 

The sending of the CNIP shall be performed as defined in EN 300 444 [12], clause 8.42 for external call and clause 8.44 
for internal call. Additionally, the following requirements apply: 

• An NG PART3 FP shall send the «CALLING PARTY NAME» information element using: 

UTF-8 encoded characters when the message is sent towards a NG DECT PART3 PP; 

DECT standard characters as defined in EN 300 175-5 [5], annex D (IA5 characters) when the message 
is sent towards a NG DECT Part 1 or a GAP PP. This implies that the FP translates non IA5 characters it 
supports into more or less equivalent IA5 characters if they are received in UTF-8 format from the 
network. 

NOTE: Use of an IA5 equivalent may be language specific (example: 6 replaced with oe in German), or 
non-language specific (6 replaced with o). 

7.4.17.2 Display of UTF-8 characters on PP side 

An NG DECT Part 3 PP shall be capable of displaying at least IA5 characters and shall understand UTF-8 encoding 
format (PP shall not misbehave upon reception of UTF-8 encoded characters). 

In addition to IA5 characters, an NG DECT Part 3 PP should be capable of displaying additional UTF-8 characters 
(characters with accents, and symbols for example). The set of supported characters should be in accordance with the 
network the FP is connected to, and may be country and/or language related. Guidelines for the display of UTF-8 
encoded characters are given in annex M of EN 300 175-5 [5]. 

For UTF-8 characters the PP is not able to display, the PP should use a replacement character. For example, Unicode 
'REPLACEMENT CHARACTER' (code point U+fffd, glyph ❖) could be used for this purpose. This is expected to 
happen when receiving a CNIP from a network in a foreign country (and for which the language is not supported by the 
PP). 

7.4.18 Location registration after re-lock 

The procedure shall be performed as defined in EN 300 444 [12], clause 13.2. The following text together with the 
associated clauses define the mandatory requirements with regard to the present document. 

In addition to the cases listed in EN 300 444 [12] clause 13.2, the PT shall also initiate the location registration 
procedure after a re-lock to a system, which the PT has access rights to, in the following conditions: 

• When the PP loses its synchronization to the FP, the PP shall start timer < MM.NG.01>. Upon re- 
synchronization to this FP, the PP shall stop timer < MM.NG.01>. 
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• If the PP gets re-synchronized after expiry of timer < MM.NG.01>, the PP shall execute the locatilon 
registration procedure after re-synchronization to this FP. 

• If the PP get re-synchronized before expiry of timer < MM.NG.01>, the PP may execute the location 
registration procedure after re-synchronization. 

Refer to clause A.2 for the value of timer < MM.NG.01>. 

If the conditions which are described above apply the PP indicates its transition back to synchronized mode to the FP by 
executing the location registration procedure, because the PP might have missed some events notifications (see 
clause 7.4.1). 

NOTE: The FP will then send some notification to re-synchronize the PPs from events notification perspective if 
necessary (e.g. missed calls notification). 

7.4.19 PT alerting using pattern signalling 

The procedure shall be performed as defined in EN 300 444 [12], clause 8.14. The following text together with the 
associated clauses define the mandatory requirements with regard to the present document. 

• By default, the FP shall use only one of the possible values for the <Signal value> field: 

40H for internal incoming call ('Alerting on - pattern 0'). 
41H for external incoming call ('Alerting on - pattern 1'). 

• A PT shall respond at least to alerting values 40H and 41H. 

NOTE: The PT should preferably ring with different tones for internal and external calls. 

7.4.19.1 External call additional requirements for systems supporting 'Associated 
melody' field per contact in the Contact List 

External call additional requirements for a PT supporting Associated melody' per contact: 

• The PT shall set the corresponding terminal capability bit: "support of associated melody per contact". 

• The PT shall respond to alerting values 41H to 47H. 

• The PT shall be capable of setting the 'associated melody' field for each contact of the FP Contact List. 
External call additional requirements for a FT supporting the 'associated melody' field of the Contact List 

• The FT shall use the appropriate alerting value 41H to 47H toward PTs declaring "associated melody per 
contact" capability bit (see clause 7.4.10.5.7). 

• The FT shall use only alerting value 41H toward all other handsets whatever the defined 'associated melody' 
filed value for the contact. 

NOTE: Other handsets may be GAP, PARTI or PART3 PPs not setting the "support of associated melody per 
contact" capability bit. 

7.4.20 Date and Time recovery 

The present procedure applies to a PP and to a FP. It allows the PP or FP (or both) to recover a correct date and time 
from the peer entity, in specific cases where the entity date and time is not valid (e.g. after a boot/reboot of the entity). 

7.4.20.1 Addressed use cases and definitions - PP capability bit 

(Local) Date and Time (on PP or FP side): It is the device clock value. 

DECT system date and time: Alternative name on FP side for the local Date and Time. 
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The Date and Time recovery" procedure addresses the following use cases: 

• Use case 1: one of the registered PPs boots or reboots (see clause 7.4.20.2). The local date and time of the 
PP may become undefined as a result. The present procedure allows the PP to recover a valid date and time 
from the FP. This avoids the PP to arbitrarily display a default date and time (e.g. 00:00 and default date). It 
also avoids the user having to manually re-enter values for them (on the concerned PP or another PP). 

• Use case 2: the FP boots or reboots and FP Date and Time becomes invalid as a result (see 

clause 7.4.20.3). Until the "DECT system date and time" is regularly updated through an independent process 
(e.g. PT initiated Date and Time synchronization, retrieval from the network, etc), the call logs date and time 
could be temporarily incorrect and in particular cause sorting problems. The present procedure avoids using 
undefined values in the mean time. 

NOTE 1: Use case 2 does not happen if the FP uses a real time clock able to maintain the clock value even when 
the device is switched off. 

Valid date and time values: The "local Date and Time" shall be marked as "valid" as soon as it is set through one of 
the following methods: 

• via the regular "Date and time" synchronization ("regular" date and time setting); OR 

• via the "Date and Time recovery" procedure (date and time recovered from peer entity after a boot or reboot). 

NOTE 2: On PP side, the validity marking is only used for FP Date and Time recovery, in order to answer the 
possible requests for recovery of the FP (see clause 7.4.20.3). 

PP capability bit: The PP shall indicate support of the "Date and Time recovery" procedure by setting the 
corresponding bit in the terminal capability IE (see EN 300 175 5 [5]). 

This capability bit shall be used for FT Date and Time recovery only (clause 7.4.20.3). 

7.4.20.2 PT Date and Time recovery 

This procedure applies to a PP with invalid Date and Time (especially after PP boot or reboot), and to the FP. 
FT requirements: 

If the system Date and Time on FT side is valid, the FT shall systematically use the "FT initiated Date and Time 
synchronization procedure" after successful PT location registration, in order to send the current system "Date and 
Time" to the PT. 

The FT shall perform this procedure independently of the "Clock master" setting value (PT or FT). 

NOTE 1: As indicated in clause 7.4.20.1, the FT sends the current system Date and Time even if the PT does not 
indicate support for the "Date and Time recovery procedure". 

PT requirements: 

As indicated in clause 7.4.2, the PP shall update its local date and time when receiving the {FACILITY} message from 
the FP (independently of the clock master setting value). 

NOTE 2: This procedure is initiated by the FP independently of the PT side Date and Time validity. The PP updates 
its Date and Time even if it was already valid. 
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{FACILITY «Time-Date The current (system) time/date' 
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Figure 79: After successful PT location registration, the FP systematically uses 
the "FT initiated Date and Time synchronization procedure 

7.4.20.3 FT Date and Time recovery 

This procedure applies to a FP with invalid Date and Time (especially after FP boot or reboot), and to PPs registered to 
that FP. 

FP requirements: 

The FP shall attempt to recover a valid date/time so that it should get a valid Date and Time at the latest 5 minutes after 
it has become invalid. More specifically, at least one of the following two methods shall be used: 

• Method 1: the FP may send a Request to send current time/date to any PP implementing the "Date and Time 
recovery" procedure. The FP shall use the PP "Date and Time recovery" capability bit in order to know if a PP 
implements the procedure. 

• Method 2: the FP may attempt to retrieve a correct Date and Time from any other available source. 

The FP may try a combination of method 1 and method 2 in any order, until it gets a valid Date and Time. 

NOTE 1: In method 1, the request may be sent independently of any location registration of the PPs (i.e. before or 
after locate request). 

EXAMPLE 1 : For method 2, the FP could attempt to retrieve a correct Date and Time from the network. 

EXAMPLE 2: For method 2, a rebooting FP may back up its own clock value in non-volatile memory before the 
reboot, in order to set its clock again to a correct time after the reboot (i.e. stored clock value plus 
average reboot time. This is only applicable for a reboot, in which case the FP is aware that it has 
been switched off for a very short defined time interval and may therefore confidently use the 
stored clock value. 

EXAMPLE 3: For method 1, the FP tries with all registered PPs implementing the "Date and Time recovery" 
procedure, one after the other until it succeeds. 

EXAMPLE 4: Method 2 then method 1: the FP retrieves Date and Time values from the memory at boot time as 
fallback values and then tries to retrieve Date and Time values from the PPs. 

The FP could fail in the worst case (none of the tried methods was successful). However, the FP shall not give up before 
it at least tries method 1 with all registered PPs implementing the "Date and Time recovery" procedure (using a Request 
to send current time/date). 

NOTE 2: In other words, use of a Request to send a valid date/time toward PPs is only mandatory if all of the other 
tried methods failed. However, this method may be tried before this happens. 

The two methods may be attempted whatever the clock master setting. 

NOTE 3: However, for a "PP" clock master setting, a FP using method 2 should preferably avoid retrieving the date 
and time from the network, as the user might have purposely set the clock to a time different from the 
local time (e.g. 10 minutes ahead of time). 
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A Request to send current time/date shall use a {FACILITY} message including a «TIME-DATE» IE with a 
dedicated interpretation value (see table 74 and EN 300 175-5[5], clause 7.7.50), as indicated in table 74. 



Table 74: Values used within {FACILITY} message for a Request to send current time/date 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Time-Date» 










<Coding> 


1 1 B 


Time and Date 




<lnterpretation> 


4H 


Request to send current time/date 




<Time/date> 




absent 



Upon reception of an answer to this request: 

• the FP shall mark its own Date and Time (system Date and Time) as valid. 

NOTE 4: As indicated in clause 7.4.2, the FP systematically updates its local date and time when receiving the 
{FACILITY} message from the PP. 

■ If the clock master setting is "FP", the FP shall retransmit this valid Date and Time to all other 
registered PPs. 

NOTE 5: For a "PP" clockmaster, the Request to send current time/date is a way for the FT to trigger the usual "PT 
initiated Date and Time synchronization procedure". Once triggered, this procedure is performed 
unchanged. This includes retransmission of the valid Date and Time to all other registered PPs. 

PP requirements: 

Upon reception of a Request to send current time/date the PP shall answer the request in one of the following two ways: 

• If the PT has a valid Date and Time, it shall answer using the usual "PT initiated Date and Time 
synchronization procedure". 

• If the PT has NO valid Date and Time, it shall answer using the dedicated error message: No valid time/date 
available. 

A "No valid time/date available" error message shall use a {FACILITY} message including a «TIME-DATE» IE 
with a dedicated interpretation value (see table 75 and EN 300 175-5[5], clause 7.7.50), as indicated in table 74. 



Table 75: Values used within {FACILITY} message for a No valid time/date available 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Time-Date» 










<Coding> 


1 1 B 


Time and Date 




<lnterpretation> 


5H 


No valid time/date available 




<Time/date> 




absent 
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PT2 



PT1 



FT 



{FACILITY «Time-Date 'Request to send current time/date' »} 



If PT has valid date & time: Use of PT initiated Date and Time synchronization procedure : 
{FACILITY «Time-Date 'The current time/date' »} 



FT updates system date 
and time and considers 
it as 'valid' 

In case PP is clock master, usual retransmission to other PTs with FT initiated Date 
and Time synchronization procedure : 

{FACILITY «Time-Date 'The current (system) time/date' »} 



If PT has no valid date & time: After error message, FT retries with another PT : 

{FACILITY «Time-Date 'No valid time/date available' »} ^ 
{FACILITY «Time-Date 'Request to send current time/date' »} 



NOTE: A positive answer to FT request is a usual use of the "PT initiated Date and Time synchronization 
procedure", with re-transmission of date and time to other PTs. 

Figure 80: FP requests for PT current date and time 

7.5 Data Link Control (DLC) layer procedures 

This clause specifies the additional DLC layer procedures, messages and information elements required in New 
Generation DECT Extended Wideband Speech Services not described in TS 102 527-1 [21] or in EN 300 444 [12] 
(GAP), or incorporating modifications to the description given in these specifications. 

7.5.1 DLC services 

The requirements of TS 102 527-1 [21], clause 7.5.1 shall apply. 

7.6 Medium Access Control (MAC) layer procedures 

This clause specifies the additional MAC layer procedures, messages and information elements required in New 
Generation DECT Extended Wideband Speech Services not described in TS 102 527-1 [21] or in EN 300 444 [12] 
(GAP), or incorporating modifications to the description given in these specifications. 

7.6.1 MAC services 

The requirements of TS 102 527-1 [21], clause 7.6.1 shall apply. 

7.6.2 Frame formats and multiplexers 

The requirements of TS 102 527-1 [21], clause 7.6.2 shall apply. 
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7.6.3 Downlink broadcast 

7.6.3.1 N T message 

The requirements of TS 102 527-1 [21], clause 7.6.3.1 shall apply. 

7.6.3.2 Qt - static system information 

The requirements of TS 102 527-1 [21], clause 7.6.3.2 shall apply. 

7.6.3.3 Q T - Fixed Part capabilities 

The requirements of TS 102 527-1 [21], clause 7.6.3.3 shall apply. 

Higher layer information: The management entity in the FP supplies the MAC layer with a 16-bit SDU via the 
Management Entity (ME) SAP. The content of that SDU is placed in bits < a32> to < a^j> of the Q T message. At the 

PT the MAC layer passes the 16 bits out through the ME SAP to the management entity. 
For the setting of the higher layer information bits see clause 7.3.9.1 of TS 102 527-1 [21]. 

7.6.3.4 Qt - Extended Fixed Part capabilities 

The requirements of TS 102 527-1 [21], clause 7.6.3.4 shall apply. 

Higher layer information: The management entity in the FP supplies the MAC layer with a 23-bit SDU via the 
Management Entity (ME) SAP. The content of that SDU is placed in bits <a25> to <a47> of the Q T message. At the PT 
the MAC layer passes the 24 bits out through the ME SAP to the management entity. 

No higher layer information for New Generation DECT; parts 1 or 3 is broadcasted in Q T - Extended Fixed part 
capabilities. 

7.6.3.5 Qt - Extended Fixed Part capabilities part 2 

The FT shall be capable of sending and the PT shall be capable of receiving and processing the Q T message as defined 
in EN 300 175-3 [3], clause 7.2.3.1 1 with the following values. 



Table 76: Values used within Extended FP capabilities part 2 



MAC message 


Field within the 
message 


Standard values within 
the MAC message 


Normative action/comment 


«FP capabilities» 


<Qh> 


C 






<a12> 


1 


Long slot j=640 




<a13> 


0,1 


Long slot j=672 (if supported) 




<a23> 


0,1 


"no emission" mode: preferred carrier 
number mode (CN) 



Setting of bit a 23: "no emission mode" 

a 23 = 1 : variable preferred CN /every CN possible. 
a 23 = : fixed preferred CN. 
The preferred carrier number is selected and broadcasted by the FT (PT broadcast info). 
FT: 

if (a 23 =1), then DummyPointer-wakeups on all carriers should be done after reset; 

if (a 23 = 0), then DummyPointer-wakeup only on the known preferred carrier should be done after reset. 
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PT: 

check capability "no emission" mode: preferred carrier number mode; 

if (a 23 =1), then DummyRequest-wakeups on all carriers should be done after reset or asynchronous 
mode; 

if (a 23 = 0), then DummyRequest-wakeup only on the known preferred carrier should be done after reset 
or asynchronous mode. 

Higher layer information: The management entity in the FP supplies the MAC layer with a 24-bit SDU via the 
Management Entity (ME) SAP. The content of that SDU is placed in bits <a24> to <a47> of the Q T message. At the PT 
the MAC layer passes the 24 bits out through the ME SAP to the management entity. 

For the setting of the higher layer information bits see clause 7.4.9.2.2. 

7.6.3.6 Q T - SARI list contents 

The requirements of TS 102 527-1 [21], clause 7.6.3.6 shall apply. 

7.6.4 Paging broadcast 

The requirements of TS 102 527-1 [21], clause 7.6.4 shall apply. 

7.6.5 "no-emission" mode 

The requirements of EN 300 175-3 [3], clauses 7.1.2, 7.2.3.11, 7.2.4.3, 7.3.5.3, 9.4 and 11.11 shall apply. 

7.7 Physical layer (PHL) requirements 

7.7.1 Modulation 

The FT and PT shall support 2 level Gaussian Frequency Shift Keying (GFSK) modulation as defined by 
EN 300 175-2 [2], clause 5. 

7.7.2 Slot type (Physical packets) 

The requirements of TS 102 527-1 [21], clause 7.7.2 shall apply. 

7.8 Requirements regarding the speech transmission 

7.8.1 General 

The requirements of TS 102 527-1 [21], clause 7.8.1 shall apply. 

7.8.2 Speech codecs 

The requirements of TS 102 527-1 [21], clause 7.8.2 shall apply. 

7.8.3 Audio performance requirements 

The requirements of TS 102 527-1 [21], clause 7.8.3 shall apply. The status of each feature shall be as defined by 
tables 8 (see clause 6.8) and 2 (see clause 6.3) of the present document. 
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7.9 Management procedures 

All procedures described in GAP (EN 300 444 [12], clause 13) shall be supported. Higher layer capability FP broadcast 
shall be set as described in clause 7.4.9.2 of the present document. 

7.10 Application procedures 

This clause specifies the additional application layer procedures, messages and information elements required in New 
Generation DECT Extended Wideband Speech Services not described in TS 102 527-1 [21] or in EN 300 444 [12] 
(GAP), or incorporating modifications to the description given in these specifications. 

7.1 0.1 Easy PIN code and easy pairing registration 

The "Easy PIN code registration" and "Easy pairing registration" features use common procedures (see clause 7.10.1.3) 
and specific procedures (see clauses 7.10.1.1 and 7.10.1.2 respectively). 

7.10.1.1 Easy PIN code registration 

7.10.1.1.1 Searching mode and PIN code requests 

The access rights procedure triggered by the user on the PP causes it to actively search for a FP broadcasting Access 
Rights requests supported' capability bit (Higher layer capabilities bit = 1, see EN 300 175-5 [5], clause F.l and 

EN 300 444 [12], annex A (informative): PP locking procedure for on-air subscription procedure). The searching mode 
shall be limited by the timer P<AP.02>. 

When a FP is found in subscription mode, the PP shall prompt the user to enter the PIN code. After PIN entering, the PP 
shall start the access rights procedure using the PIN code value for the authentication code. 

NOTE 1 : When performing easy PIN code registration, it is assumed that the PP is in close proximity to the FP, and 
therefore the PP will receive a stronger signal from that FP. The PP can use RSSI readings to speed up the 
search for the desired FP. For example: 

1) Measure the RSSI level on each channel. 

2) Synchronize on the FP with the highest RSSI value. 

3) Wait for the 344 bit to check if it is set. 

4a) If 344 is set, start the access rights procedure. 

4b) If 344 is not set, put the RFPI on a barred list and go to step 2 (or 1) to find other FP. 

NOTE 2: It is recommended to request the PIN code entering after locking to a FP in subscription mode, because 
this procedure may be common with easy pairing search mode request procedure (see clause 7.10.4). 
Nevertheless it can be done before. 

NOTE 3: For security purposes, it is recommended to use a PIN value different from default '0000' value. In this 
case it could be convenient to indicate the device PIN value with a sticker on the FP. It could also be 
recommended to change the PIN value in the user manual. 
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PP-NWK PP-MAC 

1 , 

I Enter Pin Code^ 



Use entered ■ 
PIN code as 
authentication 
code 



FP-MAC FP-NWK 



^0+1=3 (Access rights supported^] 



ACCESS-RIGHTS-REQ 



KFY-AI I OCATF 



AUTH-REQUEST 



AUTHENTICATE-REPLY 



ACCESS-RIGHTS-ACCEPT 



Q H=3 (Access rights supported=0) 



_Registration 
mode 



Figure 81 : Easy PIN code registration mode 



7.1 0.1 .2 Easy pairing registration 

7.10.1.2.1 Easy pairing registration description 

Easy pairing feature simplifies the registration process by not requesting any PIN code to the user when the PIN code is 
set to default "0000" value. 

When feature is implemented, related procedures shall be valid at first power ON of a non registered handset and at any 
additional further registrations. 

The PP will systematically try to register with the default "0000" PIN code. In the case of failure, the PP will 
automatically switch back to the easy PIN code registration feature process and corresponding procedures. 

From security point of view, successful easy pairing is equivalent to default 0000 PIN code registration which is less 
secure than any non 0000 PIN code registration. As a consequence, for easy pairing registration, the user should be 
instructed to monitor the registration user feedback (see clause 7.10.6). 

As additional security and for user convenience it is recommended to use the "Base station name selection" (see 
clause 7.10.7). This allows checking that registration of a PP is ongoing on the correct FP. 

7.10.1.2.2 Base station limited registration mode 

The FP shall have a physical or a logical button to trigger the access rights procedure. 

When the button is pressed on the FP, the FP shall set its broadcasting 'Access Rights supported attributes' capability bit 
to enable the on air subscription (see clause 7.4.9.1 "Higher layer information in FP broadcast" and EN 300 444 [12] 
clause 13.6 "Broadcast attributes management"). 

When the access rights procedure is successfully completed or when timer F<AP.01> expires, this bit shall be cleared. 

Additionally, for security reasons the FP should implement the following behaviour: before timer expiry, the FP may 
clear this bit and stop the timer if a fix number of unsuccessful PIN code registration attempts were reached. 

Nevertheless, the FP shall support at least one more registration attempt if easy pairing procedure failed before clearing 
the bit to be compatible with easy pairing registration procedure clause 7.10.1.2. 

For security reasons, the FP shall perform no more than one successful access rights procedure during the subscription 
mode. 
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7.10.1.2.3 Searching mode request 

The access rights procedure triggering by the user on the PP causes it to actively search for a FP broadcasting 'Access 
Rights requests supported' capability bit (Higher layer capabilities bit a^ = 1, see EN 300 175-5 [5] clause F.l and 

EN 300 444 [12], annex A (informative): PP locking procedure for on-air subscription procedure). The searching mode 
shall be limited by the timer P<AP.02>. 

When a FP is found in subscription mode, the PP shall start the access rights procedure using the '0000' value for the 
authentication code. If the FP rejects the access rights, the PP shall prompt the user to enter the PIN code. The PP shall 
then initiate a new access rights request with the same FP using the PIN entered value for the authentication code. 

NOTE: When performing easy pairing registration, it is assumed that the PP is in close proximity to the FP, and 

therefore the PP will receive a stronger signal from that FP. The PP can use RSSI readings to speed up the 
search for the desired FP. For example: 

1) Measure the RSSI level on each channel. 

2) Synchronize on the FP with the highest RSSI value. 

3) Wait for the a^ bit to check if it is set. 



4a) If is set, start the access rights procedure. 



4b) If is not set, put the RFPI on a barred list and go to step 2 (or 1) to find other FP. 



Use '0000' value <■ 
as authentication 
code 





Q H= 3 (Access rights supported=1) 




^Qh=c (NG-DECT Part 3 supported=1 ) 
K 




ACCESS-RIGHTS-REQ 




KEY-ALLOCATE 


► 


< 


AUTH-REQUEST 






AUTHENTICATE-REPLY 


> 


< 

< 


ACCESS-RIGHTS-ACCEPT 






Q H= 3 (Access rights supported=0) 







-Push button 



V 



Within timer 
F<AP.01> 



Figure 82: Easy pairing when PIN is set to default '0000' value 



ETSI 



268 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



PP-NWK PP-MAC 



FP-MAC FP-NW 



Use '0000' < 
value as 
authentication code 



Enter Pin Code 



Use entered — 
PIN code as 
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Q H= 3 (Access rights supported=1) 



Q H=C (NG-DECT Part 3 supported=1) 



ACCESS-RIGHTS-REQ 



KEY-ALLOCATE 



AUTH-REQUEST 



AUTHENTICATE-REJECT 



ACCESS-RIGHTS-REJECT 



ACCESS-RIGHTS-REQ 



KEY-ALLOCATE 



AUTH-REQUEST 



AUTHENTICATE-REPLY 



ACCESS-RIGHTS-ACCEPT 



Q H= 3 (Access rights supported=0) 



.Push button 



Within timer 
F<AP.01> 



Figure 83: Easy pairing when PIN is not set to default '0000' value: switching back to PIN entry 

Backward compatibility management: when a PP is in front of a FP without easy pairing capability, here are three 
possible behaviours of the PP (among several others and left free to implementer): 

1) The PP uses the easy pairing feature, in case of failure, requests the PIN code, exactly as in front of a FP with 
easy pairing. The PP does not take into account the NG-DECT Part 3 capability bit (bit < a 2 9> in the Extended 
Higher Layer Capabilities part 2). This means easy pairing feature is always used on the PP independently of 
the FP type. 

3) The PP uses the easy pairing feature but in case of easy pairing failure, the PP uses the NG-DECT Part 3 
capability bit to warn the user that re -triggering of the FP registration button might be necessary before using 
the easy PIN code registration feature. This deals with the case where the FP might not remain in registration 
mode when the PP easy pairing attempt fails (could occur on some GAP FP for example). 

4) The PP detects that the FP is not supporting the 'easy pairing registration' by the absence of the NG-DECT 
Part 3 capability bit from the beginning and decides not to use the easy pairing feature but to use easy PIN 
code registration feature instead. This behaviour has the drawback not to use easy pairing. So it should be 
implemented only if behaviour 1 and 2 cannot be implemented. 



7.1 0.1 .3 Common procedures to easy PIN code and easy pairing 



7.10.1.3.1 Registration mode automatic access 

When a PP that it is not registered to any FP is powered on, the PP shall start in a mode where the user is directly 
invited to trigger the access rights procedure. Upon user acknowledge, the access right procedure shall start. 

It shall be possible for the user to leave this mode to switch back to idle mode. 

For any further registrations on the PP (additional registration to the initial one), the registration mode should also be 
easily accessible from the user point of view. 
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7.10.1.3.2 Base station name selection 

This clause applies only to PP with a display capability. 

The FP shall broadcast its name during the subscription mode. The name shall be composed of up to 17 characters to fit 
in a {CLMS-FIXED} message. The name could be set to the manufacturer and model of the phone by default (see 
note 1) and could be changed by the user to a friendly name. 

As soon as a FP with set to 1 is found within the FP searching process based on the RSSI, the name shall be 
displayed by the PP. 

EXAMPLE 1 : The PP may display a list of FP names in subscription mode for selection by the user. 

EXAMPLE 2: The PP may display only the selected FP (taking into account the best RSSI indication for 
example). 

The PP will then start the access rights procedure with the selected FP (see clauses 7.10.2 or 7.10.5). The name shall be 
displayed by the PP with the result of the complete registration procedure. 

The FP shall transmit its name information frequently during the subscription mode (i.e. during timer F<AP.01>). At 
least, the first segment of the FP name shall be transmitted within one period of F<AP.03> after the FP capabilities 
information transmission in order to receive it very quickly on PP side. 

NOTE 1: When there are several FP of same type in range in subscription mode, this can be confusing. Therefore, it 
is recommended to set a unique name by default. For a DECT phone, the name could be composed of the 
phone model reference with the two last bytes of RFPI and indicated with a sticker on the FP. For a 
DECT FP integrated within a gateway/PBX, the name could be composed of the gateway/PBX model 
reference with additional unique identifier. 

NOTE 2: The PP should take into account the FPs not supporting the base name broadcasting (e.g. GAP or 

NG-DECT Part 1 base stations). In that case, the PP may display a message like "Unknown" or the RFPI. 

NOTE 3: With this procedure, the overall process to select a base in registration mode is a little bit longer but it 
really improves the security. 
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FP name broadcasting is initiated by including the «NETWORK-Parameter» information element in the 
{CLMS-FIXED} message. The procedure to construct a multi-section {CLMS-FIXED} message shall be performed as 
defined in EN 300 175-5 [5], clause 8.3. 



PT-IWU 



PT 



FT 



FT-IWU 



MNCL_UNIT_DATA-req 



«NETWORK-parameter = 
Device Name» 



Qh = 3 (Access rights supported=1 ) 




< 


MNCL UNIT DATA-req 


CLMS-FIXED 
4 


* = — 

«NETWORK-parameter = 
Device Name» 


Address section 




CLMS-FIXED 
< 


F <AP 03> 


Data section 1 


CLMS-FIXED 
■4 




Data section 2 




CLMS-FIXED 
< 




Data section 3 


MNCL UNIT DATA-req 




4 

«Name» 


Qh = 3 (Access rights supported=0) 
4 









Registration mode 



Within 
timer 
F<AP01> 




Figure 84: Base station name broadcasting 
Table 77: Values used within the {CLMS-FIXED} message 1 st segment 



Information element 


Field within the 
information element 


Standard values 
within the field/IE 


Normative action/comment 


«A» 




1 


Address section 


«CLMS header» 




010B 


Multiple sections/Standard 


«Address» 




CFFFH 


Connectionless Group TPUI 


«Protocol 
Discriminator» 


<Second Discriminator 


000001 B 


DECT Information elements coding 


«Length ldentifier» 




Any 


Indicates implicitly the number of data 
sections to follow 



Table 78: Values used within the {CLMS-FIXED} message 2 nd segment 



Information element 


Field within the 
information element 


Standard values 
within the field/IE 


Normative action/comment 


«A» 







Data section 


«CLMS header» 




000B 


Data section number - (1 st ) 


«DATA/Fill» 




41 H 


NETWORK parameter (octet 1) 






Any < 20 


Length (octet 2) 






00010000B 


Discriminator: Device name (octet 3) 






Name 


First character of name (octet 4) 
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Table 79: Values used within the {CLMS-FIXED} message k segment 



Information element 


Field within the 
information element 


Standard values 
within the field/IE 


Normative action/comment 


«A» 







Data section 


«CLMS header» 




K 


Data segment (k+1) 


«DATA/Fill» 




Name 








Name/Fill 








Name/Fill 








Name/Fill 





7.10.1.3.3 Registration user feedback 

In order to improve the security, the FP and the PP shall give a feedback to the user of the registration process through a 
user interface (for example a display, a LED or a buzzer). 

The feedback given on the user interface of the PP and the FP shall be as a minimum the following status of the 
registration process with the following states: 

• Registration in progress state: 

Condition of entrance: the PP is looking for or is locked on a FP in subscription mode and the protocol is 
exchanging messages. 

Recommended user action: wait for protocol to finish. 

• Registration error state: 

Condition of entrance: some error occurred, such as failed to find a peer device, or to complete the access 
rights procedure (e.g. authentication failed). 

Recommended user action: wait then try again. 

• Registration success state: 

Condition of entrance: protocol procedure is complete and successful. 
Recommended user action: try to make an outgoing call request. 
EXAMPLE: Find below typical cases where the registration error state is reached: 

■ PP side: failed to find the peer device during search mode timer. 

■ PP side: access rights procedure failed (for example due to wrong PIN code). 

■ FP side: no device successfully registered when running the base station limited registration mode 
procedure. 

NOTE: On FP side, if access rights procedure fails, FP should wait until the Access Rights supported attributes' 
capability bit is cleared (registration mode ended) to indicate the error state. This is necessary to ensure 
correct support of the easy pairing procedure in the specific case where FP uses a non default '0000' PIN 
code. 

The proposed user feedback with corresponding user interface allows user to check that registration on the correct FP 
was successful. This is an additional security especially in the case of the easy pairing procedure which is less secure 
than the PIN code registration procedure. 

The user should be aware that during the registration mode unwanted PP could join the FP. The user should be 
instructed to monitor the user interface, especially to check the success indication on both sides for security 
considerations. This verification will prevent the PP from joining a FP that was not selected or to prevent another PP 
from joining the selected FP. 

Type of user interface is left free to implementers. For example, the user interface could be a display on the PP side and 
a LED on the FP side. It could also be an audio tone indication or any other richer user interface (displays on both sides 
for example). 
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7.10.2 Handset locator 

On FP side, a software or hardware button shall trigger this procedure. 

The FP shall present an incoming external call to all idle PPs registered to the FP. This incoming call shall respect the 
present document: 

• The FP shall send a call identification and a call status indication in IE «CALL-INFORMATION» of 
{CC-SETUP} message. 

• The FP shall send the information element «Calling Party Name» with the Presentation indicator> field 
set to 'Handset locator' value. 

However, one exception applies: 

• The FP shall omit line identification as this call is not related to any line and to give the possibility for a 
cleaner call presentation on PP side. 

On PP side, the call shall be presented as an incoming call. If PP has ringing capabilities enabled, the PP shall ring. 

NOTE 1: It is recommended that the FP sends a CNIP with a name related to the current procedure, for example 
"Handset locator". 

NOTE 2: The 'Handset locator' value of Presentation indicator> field in CNIP might be used by the PP to trigger 
the ringing even if it is disabled, or to increase the ringer volume in that particular case. 



Table 80: Values used within the {CC-SETUP} or {CC-INFO} message 
for handset locator internal call CNIP 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Calling party 
name» 








Presentation indicator 


11 


Handset locator 


<Used Alphabet> 


All 




<Screening indicator 


All 




<Calling party name> 


All 


'Handset locator' for example 



The procedure is stopped when incoming call is accepted by one of the PPs. In this case, the FP shall immediately 
release the call on this particular PP and stops incoming call presentation to other PPs. 

NOTE 3: Other possible stops of the procedure are out of the scope of the present document. For example the 
procedure could also be stopped: 

■ by pressing the button again on the FP side; 

■ by using a timer mechanism on FP side. 

NOTE 4: The way the call is accepted on the PP is out of the scope of the present document. For example only the 
call key could accept the incoming call. 
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Figure 85: Handset locator example where PP1 is located 



NOTE 5: The Call Control message sequence in figure 85 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

If one of the registered PPs is already involved in a call, the FP shall either: 

• Apply the current procedure to idle PPs only and leave the PP involved in its call. 

• Wait for all PPs to be in idle state before applying the current procedure to all PPs. 

NOTE 6: If an incoming call occurs while the handset locator procedure is already ongoing, the FP should stop the 
handset locator call and present the incoming call. 
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Annex A (normative): 
System parameters 

A.1 CC timers 

The values of timers provided by Call Control procedures are shown. 
<CC.NG.01> Intercept tone provision timer. 
FT value: 1 300 milliseconds. 

PT value: Not used. 

Start: A «SIGNAL» IE has been sent requesting a tone generation. 

Stop: none. 

NOTE: The 1 300 milliseconds value is compatible with the value defined by Recommendation 
ITU-T E.180 [i.10], specification for the special information tone. 

A.2 MM timers 

The values of timers provided by Mobility Management procedures are shown. 
<MM.NG.01> Unlocked mode timer. 



FT value: None. 

PT value: 60 seconds. 

Start: PP looses synchronization to the FP. 

Stop: After re-synchronization to the FP. 



A.3 Application timers 

<AP.01> Subscription mode timer. 

FT value: 120 seconds. 

PT value: Not used. 

Start: Subscription mode has been requested by the user and bit of "higher layer capabilities", 

"access rights supported", has been set. 

Stop: As soon as on-air subscription procedure is successful or bit 344 of "higher layer capabilities", 

"access rights supported", is cleared. 

<AP.02> Searching mode timer. 

FT value: Not used. 

PT value: 120 seconds. 

Start: Searching mode has been requested by the user: listen and wait for bit 344 of "higher layer 

capabilities", "access rights supported". 



ETSI 



275 ETSI TS 1 02 527-3 V1 .5.1 (201 3-03) 



Stop: As soon a as on-air subscription procedure is successful. 

<AP.03> Base station name broadcasting timer. 

FT value: 160 ms. 

PT value: Not used. 

Start: Base station name broadcasting occurrence (Higher layer capabilities FP broadcast sent). 

Stop: The first segment of the FP name is sent. 



A.4 Constants 

PI 00: FP side maximum response time allowed for an Li A command (as a complete exchange) when the answer fits in 
a single data packet last. 

The mandated value is 800 milli-seconds. 
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Annex B (normative): 
Procedure diagrams 

The following diagrams depict basic sequences that illustrate the text of present document. 

The Call Control message sequences in the following diagrams shall be understood as examples. The sequences may 
also contain different Call Control messages or Call Control messages in another order or Call Control messages with 
other contents. 

EXAMPLE: {CC-ALERTING} and {CC-CALL PROC} are sometimes not mentioned although they are 
allowed in the sequences. 



B.1 Events notification diagrams 

The following flowcharts are very basic sequences. See also annex C (especially clauses C.2.4 and C.2.5) for more 
complete examples of notifications. 

For clarity of the following flowcharts, «Call information» IE including call identifiers and line identifiers does not 
appear in some of the CC messages that convey it. Please note that they should not be omitted when implementing 
equivalent cases. 

B.1 .1 Event notification when there is no existing connection 

Use case: FP wants to send an event notification and there is no existing connection: use the CLSS procedure (page the 
PP and setup the bearer). 



PP 



FP 



NWK MAC 



MAC NWK 
LCE-REQUEST-PAGE 



access_request 



bearer confirm 



FACILITY 



«EVENTS NOTIFICATION;-;., 
«CALL-IN FORMATION, Lineld» 



Figure B.1 : Event notification when there is no existing connection 

NOTE: Line identifier may be equal to 'all lines' value. 
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B.1 .2 Event notification during existing connection 

Use case: FP wants to send an event notification when the PP is on communication: use the existing connection. 



pp 




FP 






FACILITY 






< 


«EVENTS NOTIFICATION;.;., 
«CALL-INFORMATION, Lineld» 













Figure B.2: Event notification during existing connection 

NOTE: Line identifier may be equal to 'all lines' value. 

B.1 .3 Event notification when the PP is switched on 

Use case: FP has wanted to send an event notification when PP was switched off, PP is switched on: use the location 
registration connection. 



PP 




FP 




LOCATE-REQUEST 










w 

LOCATE-ACCEPT 






< 


FACILITY 








< 


«EVENTS NOTIFICATION» 








«CALL-INFORMATION, Lineld» 





Figure B.3: Event notification when the PP is switched on 

NOTE: Line identifier may be equal to 'all lines' value. 
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B.1 .4 Event notification using call connection 

Use case: FP has wanted to send an event notification when PP was not in range, PP sends a {CC-SETUP}: use the call 
connection. 



PP 



FP 



CC-SETUP 





► 

CC-CONNECT 


< 


FACILITY 


< 





«EVENTS NOTIFICATION^ 
«CALL-INFORMATION, Lineld» 



Figure B.4: Event notification using call connection 

NOTE: Line identifier may be equal to 'all lines' value. 



B.1 .5 Event notification for "Missed call notification" 

Use case: Missed call notification message sequence. 



PP 



Alerting 



User accesses 
missed calls list 



FP 



CC-SETUP 



-< 

CC-ALERTING 


«CLIP» 


— ► 


■< 


CC-RELEASE 




« 

CC-RELEASE-COM 


RELEASE REASON, » 




« RELEASE REASON 


» 


— ► 


■< 


FACILITY 





« EVENTS NOTI FICATIONS, < Missed call, Voice, 1 

< List change indication, Missed call list, 1 > » 
« CALL-INFORMATION », Linedld » 



End of incoming call 



Missed calls list consultation using list access feature 
(Read or edit command) 



FACILITY 



« EVENTS NOTIFICATIONS, <Missed call, Voice, > » 
« CALL-INFORMATION, Lineld » 



Figure B.5: Missed call notification 

NOTE: See also clause C.2.4 for more detailed flowcharts including line identifiers and call identifiers. 
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B.2 Date-time synchronization diagrams 

These flowcharts depicts the date and time synchronization feature, but only in the cases where the FP sets the date and 
time of the PP. When implementing this feature, the FP behaviour shall follow one of the possible use cases listed 
hereafter. Please note some flexibility is allowed concerning the CC messages. 

For clarity of the following flowcharts the «Call information» IE including call identifier does not appear in the CC 
messages that convey it. Please note that it should not be omitted when implementing equivalent cases. 

EXAMPLE: The call identifier is assigned by the FP after the {CC-SETUP} message. 



B.2.1 Date-time synchronization when there is no existing 
connection 

Use case: FP wants to send a time and date synchronization and there is no existing connection: use the CLSS 
procedure (page the PP and setup the bearer). 



PP 



FP 



NWK MAC 



I 

MAC NWK 
LCE-REQUEST-PAGE 



access_request 



bearer confirm 



FACILITY «Time-Date : 



Figure B.6: Date-time synchronization when there is no existing connection 



B.2. 2 Date-time synchronization during existing connection 

Use case: FP wants to send a time and date synchronization when the PP is on communication: use the existing 
connection. 



PP 



FP 



FACILITY « Time-Date » 



Figure B.7: Date-time synchronization during existing connection 
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B.2.3 Date-time synchronization when the PP is switched on 

Use case: FP has wanted to send a time and date synchronization when PP was switched off, PP is switched on: use the 
location registration connection. 



PP 


FP 




LOCATE-REQUEST 




► 

LOCATE-ACCEPT 


FACILITY « Time-Date » 









Figure B.8: Date-time synchronization when the PP is switched on 

This use case may also be covered via the Date and Time recovery procedure defined in clause 7.4.20. 

B.2.4 Date-time synchronization using call connection 

Use case: FP has wanted to send a time and date synchronization when PP was not in range, PP sends a {CC-SETUP}: 
use the call connection. 



PP 




FP 




CC-SETUP 










CC-CONNECT 






-< 


FACILITY « Time-Date 


» 






< 















Figure B.9: Date-time synchronization using call connection 

NOTE: The line identifier is not represented here. Note that it is anyway only relevant if the synchronization is 
done in the context of an external call. 



ETSI 



281 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



B.3 List access service basic sequence diagrams 

For clarity of the following flowcharts, «Call information» IE including call identifiers and line identifiers does not 
appear in some of the CC messages that convey it. Please note that they should not be omitted when implementing 
equivalent cases. 

B.3.1 Start/end session when PP is in idle mode 



PT 



FT 



Direct PT initiated link establishment 



CC-SETUP 



IE « Basic Service < Call Class= LiA service call setup > » 
CC-CALL-PROC 



IWU-lnfo 



IE « IWU to IWU= start session, list identifier, sorting field identifiers » 

IWU-lnfo 



IE « IWU to IWU= start session confirm, session identifier, Total number, 
sorting field identifiers » 



list access 



IWU-lnfo 



IE « IWU to IWU= end session, session identifier » 



IWU-lnfo 



IE « IWU to IWU= end session confirm, session identifier » 



CC-RELEASE 



CC-RELEASE-COM 



Figure B.10: List access: start/end session when PP is in idle mode 
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B.3.2 Start/end session when a call is already established to PP 



PT 



FT 



call established 



IWU-lnfo 



IE « IWU to IWU= start session, list identifier, sorting field identifiers » 



IWU-lnfo 



IE « IWU to IWU= start session confirm, session identifier, Total number, 
sorting field identifiers » 



list access 



IWU-lnfo 



IE « IWU to IWU= end session, session identifier » 



IWU-lnfo 



IE « IWU to IWU= end session confirm, session identifier » 

Figure B.11 : List access: start/end session when a call is already established to PP 

NOTE: See also diagrams in clause C.6 for examples on list access and voice calls flowcharts. 



B.3.3 Query supported entry fields 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= query supported entry fields, session identifier » 



IWU-lnfo 



IE « IWU to IWU= query supported entry fields confirm, session identifier, list 
of supported entry field identifiers» 



Figure B.12: List access: query supported entry fields 
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B.3.4 Read entries 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 



IWU-lnfo 



IE « IWU to IWU= read entries confirm, session id, start index, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 



Figure B.13: List access: read entries 
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B.3.5 Edit entry 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= edit entry, session id, entry identifier, list of field identifiers » 



IWU-lnfo 



IE « IWU to IWU= edit entry confirm, session id » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 



Figure B.14: List access: edit entry 
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B.3.6 Save entry 



PT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= save entry, session id, entry identifier » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part k » 



IWU-lnfo 



IE « IWU to IWU= save entry confirm, session id, start index, 
entry identifier, position index » 

FACILITY (optional, depending on list) 



FT 



« EVENTS NOTIFICATION, List change notification », 
« CALL INFORMATION, Line Id » 



Figure B.15: List access: save entry 

NOTE: Alternatively the {FACILITY} message might be sent after terminating the list access session. 



B.3.7 Delete entry 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= delete entry, session id, entry identifier » 



IWU-lnfo 



IE « IWU to IWU= delete entry confirm, session id, total numb 



Figure B.16: List access: delete entry 

NOTE: The list has changed once this procedure has been performed. PP should read list again starting from 
index of the first entry which was deleted. 
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B.3.8 Delete list 



PT 



FT 



list access sesion 

Call id=l, call status = 'CS call connect' 
Call id=2, call status = 'CS call hold' 



IWU-lnfo 



IE « IWU to IWU= delete list, session id » 



IWU-lnfo 



IE « IWU to IWU= delete list confirm, session id » 



Figure B.17: List access: delete list 



B.3.9 Search entries 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= search entries, session id, searched value, counter, list of 

field identifiers » 



IWU-lnfo 



IE « IWU to IWU= search entries confirm, session id, start index, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 



Figure B.18: List access: search entries 
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Annex C (informative): 

Recommended implementation of procedures 
C.1 General 

In the following clauses, several examples for generic sequence charts are depicted. 

It has to be noted that the sequences are only examples, it cannot be mandatory that the message flows are always 
exactly in the described way. However it is recommended to follow the examples where possible in order to ensure 
interoperability. 



C.2 Multiple lines diagrams 

The diagrams of this clause document the "Multiple lines" feature. This feature can be used when at least the FP 
implements it. For the PP, implementing this feature means that it is aware of multiple attachments, and proposes an 
adapted MMI. 

However a PP may be attached to several lines without being aware of it, i.e. not implementing the "Multiple lines" 
feature. Such a PP would use e.g. "FP-managed line selection" (see clause 7.4.5.2.4) for outgoing calls, and would 
receive calls from these lines at the price for the user of not knowing from which line an incoming call arrives (unless 
asking the calling user). 

The "Line identification" feature is a pre -requisite for the 'Multiple lines' feature on PP side and on FP side. This feature 
allows the user to place a call on line k by keyboarding '#k' before the called number, or by introducing the 'k' value 
through a dedicated MMI. It also allows the user to know in advance on which line a call is received through the 
display. With the "Line identification" feature alone, the PP still would not be able to propose a menu with the set of 
attached lines presented and to choose from. 

C.2.1 Attaching a new PP to one or several lines 

Use case: the user hast just registered a new PP, then the user is invited to select the line(s) to which the new PP is 
attached to (PP managed attachment). This use case can also be used later to change the handsets attachment to the 
lines. 

We assume that the new registered PP is the terminal number 'm'. 
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PP FP 

ACCESS-RIGHTS-REQUEST 



-> 



ACCESS-RIGHTS-ACCEPT 



LOCATE-REQUEST 



LOCATE-ACCEPT 



^ TEMPORARY-IDENDITY-ASSIGN-ACK < TPUI ldN=m > 



Line settings start session. 'Total number of entries' = N (lines) 




for(n e 1.. N) 



handsets' field of each line for the new registered PP: 

IWU-INFO 



IE « IWU to IWU= read entries, session id, start index=n, counte r=forward/1 , 
list of field identifiers = Line Id id, Line name id, Attached handsets id » 

IWU-INFO 



IE « IWU to IWU= read entries confirm, session id, counter=1 » 
IWU-INFO 



IE « IWU to IWU= data packet, session id, content part = n th entry content » 

IWU-INFO 



IE « IWU to IWU= edit entry, session id, entry identifier = entry id n, 
list of field identifiers= Line Id id, Line name id, Attached handsets id » 

IWU-INFO 



IE « IWU to IWU= edit entry confirm, session id, start index = n » 
IWU-INFO 



IE « IWU to IWU= data packet last, session id, content part= n th entry content » 



user may update the 'Attached handsets' field for n ,h line in line settings list 
to attach the new registered PP to the n th line 



IWU-INFO 



IE « IWU to IWU= save entry, session id, entry identifier entry id n » 
IWU-INFO 



IE « IWU to IWU= data packet last, session id, content part= n th entry updated » 

IWU-INFO 



IE « IWU to IWU= save entry confirm, session id, entry identifier = entry id n, 



FP notifies list change notification to all PPs attached to the line n 



line settings end session 



Figure C.1 : Attaching a new PP to one or several lines 

NOTE 1: The above diagram assumes that only one "data packet" command is necessary for reading one entry 
content, i.e. the 'data packet last' command is received directly. 

NOTE 2: As an alternative, all entries in the Line Settings List could be read all at once with one read entries 
command. 
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C.2.2 Outgoing first call on a line 

For each use case, two sub use cases at least are handled: Line identification by PP, or FP managed line selection. 

C.2.2.1 PP attached to 1 line 

See below, clauses C.2.2.2. 1 and C.2.2.2.2, as there is no difference from the case when a PP is attached to several lines 
(the only line-id is sent at call setup by a PP attached to only one line). 

C.2.2.2 PP attached to several lines 

Clauses C.2.2.2. 1 and C.2.2.2.2 implement variants of the same use case: the PP implements the "Line identification" 
feature and sends the line-id when setting up the call. 



C.2.2.2.1 Line identification by PP using «CALL-INFORMATION» 

Use case 1: the PP selects a line on a call-by-call basis using «CALL-INFORMATION» IE. 

PP FP Network 

CC-SETUP 



K< CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 



» 



CC-SETUP-ACK 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call-id 1 ' > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 

« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call-id 1 ' > 



Use of line u 
for calling 
'called number' 




Figure C.2: Line identification by PP using «C ALL-INFORM ATION» 

NOTE: As "Call identification" is mandatory for NG PART3, The call identifier notification is represented, 

although it is somehow independent of the "Multiple lines" feature. The line identifier value is repeated in 
the «CALL INFORMATION» IE together with the indication of the 'line type information'. 

C.2.2.2.2 Line identification by PP using the «MULTI-KEYPAD» 

Use case: a GAP or Part 1 PP selects a line on a call-by-call basis using « MULTI-KEYPAD» IE (e.g. the user used 
the keyboard to select the line) and sends the complete 'called number' in the same information element. For a GAP or 
Part 1 PP, no line selection confirmation is sent to the PP. See also clause 7.4.5.2.3. 
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PP 

attached to line u e 1..9 



FP 



Network 



CC-SETUP 



CC-SETUP-ACK 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = '23 3u'H 

+ called number > » 



Use of line u 
for calling 
'called number' 




Figure C.3: Line identification by GAP or Part 1 PP using «MULTI-KEYPAD» 

NOTE: Restriction to [0..9] interval for the line id value is in place here because «MULTI-KEYPAD» is used 
for sending the line id. 

C.2.3 First incoming call on a line 
C.2.3.1 PP attached to 1 line 

See below, clause C.2.3.2, PP attached to several lines, as there is no difference with the case when a PP is attached to 
several lines. 

C.2.3.2 PP attached to several lines 



Use case: the PP is attached to several lines. An incoming call on line u is presented. 
PP 

attached at least to 
line u 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = = 'call-id 1' > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup' > 




Network 



Incoming call to line u 
from 'calling number' 



Figure C.4: First incoming call, PP attached to several lines 
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C.2.4 Missed call 

Use case: An incoming call on line u is not answered, and there are already two 'unread' missed calls in the list. The PP 
is attached to one or several lines. A 'list change indication' for the Missed Calls List is sent together with the 'missed 
call notification' (see clause 7.4.1.3, 'simultaneous list change indication' subsection). The 'missed call notification' and 
related 'list change indication' are sent in this example just after the incoming call release. 

PP 

attached at least to 
line u 

CC-SETUP 

-4 

« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information' > 

< Identifier value = 'xy'B > 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 

< Identifier type/subtype = Call status' > 

< Identifier value = CS call setup' > 

» 

CC-RELEASE 



CC-RELEASE-COM 



FACILITY 

< 

« EVENTS-NOTIFICATION, 

< Event type = 'Missed call' > , 

< Event sub type = 'A new external missed voice call 
just arrived' > 

< Event multiplicity = 3 > < 

< Event type = 'List change indication' > , 

< Event sub type = 'Missed call list' > 

< Event multiplicity = 'number of missed called in the 
missed calls list' for the specified line> 

« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = Line identifier for external call' > 

< Identifier value = u > 

» 



Figure C.5: Missed call 

NOTE: The list change indication for the Missed Calls List accompanying the 'missed call notification' is 
mandatory. 



FP 



Network 




Incoming call to line u 
from 'calling number' 



There are 3 'unread' 
missed calls relating to 
the specified line in the 
'Missed Calls List', 
including the one 
triggering this 
notification 
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C.2.5 Voice message waiting indication on a specific line 

Use case: a voice message has been left in the voice mailbox of line 'u' which already contained one message, a voice 
message waiting indication is sent to each PP attached to this line. For this network, the 'number of messages' notified 
corresponds to the total number of messages in the voicemail box (see clause 7.4.1.2). 

PP 

attached at least to 

line u FP Network 



FACILITY 


y\ 

/ Voice message waiting 
\^ indication on line u 






« EVENTS-NOTIFICATION, 

< Event type - 'Message waiting'>, 

< Event sub type = 'Voice' > 

< Event multiplicity = 2 

<< CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Relating-to line identifier' 

< Identifier value = u > 

» 




There are 2 messages remaining in 
the voicemail box of the specified 
line , including the new one 
triggering this notification 









Figure C.6: Voice message waiting indication on a specific line 



C.2.6 Missed call notification scenario 

Use case: The following list of incoming calls and other events occurs. None of the incoming calls has been answered. 

1) Incoming external call on line 1 (clause C.2.6. 1). 

2) Two incoming external call on line 2 almost simultaneously (clause C. 2.6.2). 

3) Incoming internal call (clause C.2.6.3). 

4) Incoming external call on line 1 (clause C.2.6.4). 

5) A PP reads one of the two 'unread' entries for line 1 in the Missed Calls List (clause C.2.6.5). 

6) A PP reads the remaining 'unread' entry for line 1, and a missed call arrives on line 1 almost simultaneously 
(clause C.2.6.6). 
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C.2.6.1 After call on line 1 



Table C.1 : Missed Calls List related notifications after event 1 (see clause C.2.6) 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 










<Event type> 


1 


Missed call 




<Event sub type> 


1 


A new external missed voice call just 
arrived 




<Event multiplicity> 


1 


Number of new missed call in the 
Missed Calls List for the specified 
line. 




<Event type> 


3 


List change indication 




<Event sub type> 


1 


Missed Calls List 




<Event multiplicity> 


1 


Total number of elements in the list 
for the specified line 


«Call information» 










<ldentifier type> 





Line identifier 




<ldentifier subtype> 





Line identifier for external call 




<ldentifier value> 


1 


The line identifier value itself 



The <Event multiplicity> field for the 'list change indication' gives the total number of entries in the Missed Calls List, 
that is, the number of all ('unread' and 'read') missed calls, but for the line indicated in the «Call information» IE 
only, NOT for all lines. 

C.2.6. 2 After two almost simultaneous calls on line 2 

Here two events of the same type occur on the same line 2 almost simultaneously, and are notified together (see 
clause 7.4.1.3, 'Almost simultaneous events'). 



Table C.2: Example Missed Calls List related notifications after event 2 (see clause C.2.6) 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 










<Event type> 


1 


Missed call 




<Event sub type> 


1 


A new external missed voice call just 
arrived 




<Event multiplicity 


2 


Number of new missed call in the 
Missed Calls List for the specified 
line. 




<Event type> 


3 


List change indication 




<Event sub type> 


1 


Missed Calls List 




<Event multiplicity 


2 


Total number of elements in the list 
for the specified line 


«Call information» 










identifier type> 





Line identifier 




identifier subtype> 





Line identifier for external call 




identifier value> 


2 


The line identifier value itself 



The 'Total number of elements in the list for the specified line' only counts elements for line 2, and therefore does not 
take into account the first missed call (see clause C.2.6.1) which was on line 1. 

C.2. 6. 3 After incoming internal call 

Internal missed calls are not placed in the Missed Calls List, and no notification is sent. 
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C.2.6.4 After call on line 1 



Table C.3: Missed Calls List related notifications after event 4 (see clause C.2.6) 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 










<Event type> 


1 


Missed call 




<Event sub type> 


1 


A new external missed voice call just 
arrived 




<Event multiplicity> 


2 


Number of new missed call in the 
Missed Calls List for the specified 
line. 




<Event type> 


3 


List change indication 




<Event sub type> 


1 


Missed Calls List 




<Event multiplicity> 


2 


Total number of elements in the list 
for the specified line 


«Call information» 










<ldentifier type> 





Line identifier 




<ldentifier subtype> 





Line identifier for external call 




<ldentifier value> 


1 


The line identifier value itself 



C.2.6. 5 A PP reads one of the two 'unread' entries for line 1 in the Missed 
Calls List 

Here there is no new missed call, but still a 'missed call notification' for updating the number of new missed calls. 
Absence of a new missed call is indicated through the use of subtype '02'H. 



Table C.4: Missed Calls List related notifications after event 5 (see clause C.2.6) 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 








<Event type> 


1 


Missed call 


<Event sub type> 


2 


No new missed call arrived, but the 
number of 'unread' external missed 
voice calls has, or may have, 
changed 


<Event multiplicity 


1 


Number of new missed call in the 
Missed Calls List for the specified 
line. 


<Event type> 


3 


List change indication 




<Event sub type> 


1 


Missed Calls List 




<Event multiplicity 


2 


Total number of elements in the list 
for the specified line 


«Call information» 










identifier type> 





Line identifier 




identifier subtype> 





Line identifier for external call 




identifier value> 


1 


The line identifier value itself 



C.2.6. 6 A PP reads the remaining 'unread' entry for line 1 , and a missed call 
arrives on line 1 almost simultaneously 

Here two events of different types occur on the same line 1 almost simultaneously, and are notified together (see 
clause 7.4.1.3, 'Almost simultaneous events'). 

Subtype '01'H ('New external missed call') is used, as one of the events is the arrival of a new missed call (see 
clause 7.4.1.3, 'Almost simultaneous events', rule 3). 
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However, the total number of 'unread' missed calls does not change, as the other event (of type 'Entry modified') 
decreases the number of 'unread' entries in the Missed Calls List by one. 

NOTE: If the two events had been notified separately, the notifications would have used different 'missed call 
subtypes'. 



Table C.5: Missed Calls List related notifications after event 6 (see clause C.2.6) 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


<<cvenis notiTicauon>> 










<Event type> 


1 


Missed call 




<Event sub type> 


1 


A new external missed voice call just 
arrived 




<Event multiplicity^ 


1 


Number of new missed call in the 
Missed Calls List for the specified 
line. 




<Event type> 


3 


List change indication 




<Event sub type> 


1 


Missed Calls List 




<Event multiplicity> 


3 


Total number of elements in the list 
for the specified line 


«Call information» 










<ldentifier type> 





Line identifier 




<ldentifier subtype> 





Line identifier for external call 




<ldentifier value> 


1 


The line identifier value itself 



C.3 Multiple calls diagrams 

C.3.1 First incoming call on the line or system 

Use case: the PP is attached to a multi-call line. An incoming call is presented to the line. 



PP 

attached to 
multiple-call line u 



FP 



Network 



CC-SETUP 



« CALL-INFORMATION, 



< Ident 

< Identi 

< Identi 

< Identi 

< Ident 

< Identi 

< Ident 

< Ident 

< Identi 

< Ident 



fiertype = 'Line identifier' > 
fier subtype = 'Line identifier for external calls' > 
fier value = u > 
fier type = 'Line identifier' > 
fier subtype = 'line type information' > 
fier value = 'xy'B > 
fier type/subtype = 'Call identifier' > 
fier value = 'call-id 1'> 
fier type/subtype = 'call status' > 
fier value = 'CS call setup' > 




Incoming call from 
'calling number' 



Figure C.7: First incoming call on the line or system 



NOTE: Although somehow independent of the "Call identification" feature, the line identifier notification is also 
represented, as "Line identification" is mandatory for Part 3 FPs. 
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C.3.2 Second incoming call on the line or system 

Use case: the PPs are attached to a multi-call line. A call is going on from PP1. An incoming call is presented to the 
line. For conciseness of the diagram, line identification is not represented (which corresponds to the case of an internal 
waiting call). 

NOTE: Although this possibility is not used in the following diagram, the FP is allowed to use two different call 
ids for the PP1 and PP2, as described in clause 7.4.6.1. 
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PP2 

attached to line u 



PP1 

attached to line u 



FP 



Network 



Incoming call 
presentation 



If PP2 accepts 



Call established with call id 1 (external or internal) 



CC-SETUP 



1 1 

« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 2 > 

< id type/subtype = 'Call status', value = 'CS call setup' 



Call waiting 
indication 



CC-INFO 



« SIGNAL value = 'call waiting tone' = '07'H » 
« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 2 > 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 



the call (or accepts it 


first) 


1 

CC-CONNECT 




1 

CC-CONNECT-ACK 


» 


4 1 


3C-INFO 



« CALL-INFORMATllON 

< id type/subtype 

< id type/subtype 

» 



'Call identifier', value = 2> 
'Call status', value = 'CS call connects 

, CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 2> 

< id type/subtype = 'Call status', value = 'CS k 



If PP1 accepts the (waitina) call (or acceDts it first) 



CC-INFO 



« MULTI-KEYPAD, info = '1C 35'H » 
« CALL-INFORMATION, 
< id type/subtype = 'Call identifier', value = 2> 
CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 1> 

< id type/subtype = 'Call status', value = 'CS cpll hold'; 

>> CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 2> 

< id type/subtype = 'Call status', value = 'CS c 

CC-RELEASE 
1 



CC-RELEASE-COM 

I 



Incoming call from 
calling number' 



le'> » 



all connect' 



Figure C.8: Second incoming call on the line or system 
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C.3.3 First outgoing call on the line or system 



Use case: the PP is attached to a multi-call line. An outgoing call is initiated. 

PP 

attached to 
a multiple-call line 'u' 

CC-SETUP 



CC-SETUP-ACK 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 



FP 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 

Figure C.9: First outgoing call on the line or system 



Network 



Use of line u 
for calling 
'called number' 




NOTE: Figure C.9 does not show the exchange of line identifiers. For a complete diagram, see for example 
clause C.2.2.2.1. 
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C.3.4 Second outgoing call on the line or system 

Use case: the PPs are attached to a multi-call line. A call is going on on PP1. A second external call is initiated. For 
conciseness of the diagram, line identification is not represented (which corresponds to the case of an internal outgoing 
call). 



PP2 

attached to line u 



PP1 

attached to line u 



FP 



_L 



Network 



Call established with call id 1 (external or internal) 



; If second call is 
| initiated by the PP2 



CC-SETUP 



T 

CC-SETUP-ACK 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 
» 

CC-iNFO 
■+- 



Use of line u (if 
external) for calling 
'called number' 





« MULTI-KEYPAD, < Keypad info = 'called number' > » 

« CALL-INFORMATiON, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > » 



if second call is 
initiated by the PP1 



CC-INFO 




« MULTI-KEYPAD, < Keypad info = '1C15'H > > 
CC-INFO 



« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > 

< Identifier type/subtype = 'Call status' > 

< Identifier value = 'CS call setup ack' > 

» 

CC-INFO 




Use of line u (if 
external) for calling 
'called number' 




« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type/subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > » 



Figure C.10: Second outgoing call on the line or system 
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C.4 Parallel calls complex or alternative diagrams 

This annex illustrates use cases of the "Common parallel call procedures" feature [NG1.N.7] that are not described in 
the main part of the standard (see figures of clause 7.4.3.5) but require clarification, and gives guidelines for 
implementation. More specifically, it includes: 

• Alternative use cases. 

• Limit or complex use cases that may not happen so often but illustrate the philosophy of the standardized 
procedures. 

NOTE: Clauses C.2 and C.3 deal with "Multiple lines" and "Multiple calls" specific use cases (e.g. not applicable 
in the PSTN double call case). 

C.4.1 Call identification for outgoing parallel calls 

This clause shows variants of the "Outgoing parallel call initiation" diagrams presented in the procedure itself (see 
clause 7.4.3.5.1), that correspond to variant use cases. In all the diagrams presented, the call-id is sent by the FP as soon 
as possible, (and even if the line-id is not known at this stage) so that it can be used by the PP in all subsequent 
messages concerning that call (for messages that use the call id when available). 
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C.4.1 .1 All in one PP message - line identification by PP 

Use case: The PP sends all parallel call initiation information in a single {CC-INFO} message (e.g. the user used the 
phone book before placing a parallel call). A single message sent by the PP with '1C15'H / '17'H + line-id + called- 
number. 



PP ^ r-^ FP 





<C^^Ongoing call (external or internal) with call id 




Outqoinq call initiation includinq line 




election bv the PP (not FP-manaqed) 


>: 




Line selected for the call (if external), 
by an NG-DECT Part 3 PP using the 
CALL-INFO method 

Line selected for the call (if external) 
by a GAP or NG-DECT Part 1 PP, 
using the KEYPAD method 




CC-INFO 


► 

« MULTI-KEYPAD, < Keypad info = '1C15'H/'17'H + 'called number'> 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value = 'u' > » 

CC-INFO 


► 

« MULTI-KEYPAD, < Keypad info = '1 C1 5'H / '1 7'H + '23 3u'H + 
'called number'> » 




CC-INFO 




« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 ' H> 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 


Call id assiqnement bv the FP 


CC-INFO 

4 




Line identifier is only sent to NG- 
DECT Part 3 PPs 




« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value = 'u' > 

< id type = 'Line identifier', subtype = 'line type information', 

value = 'xy'B > 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 

< id type/subtype = 'Call status', value = 'CS call proc' > 



Figure C.11: Outgoing parallel calls: all in one PP message, line identification by PP 
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C.4.1 .2 All in one PP message - FP-managed line selection 

Use case: The PP sends all parallel call initiation information in a single {CC-INFO} message (e.g. the user used the 
phone book before placing a parallel call). However, "FP-managed line selection" (see clause 7.4.5.2.4) is used. A 
single message sent by the PP with '1C15'H / 17'H + called-number, but with the special line-id value 'None'. 



PP FP 





==C^^Ongoing call (external or internal) with calMdV^^> 




Outgoing call initiation with FP-managed line selection 




Outgoing 
parallel call 
initiation 


CC-INFO 




► 

« MULTI-KEYPAD, < Keypad info = '1 C1 5'H / '1 7'H > 

< Keypad info = 'called number' > » 
« CALL-INFORMATION 

< id type = 'Line identifier', subtype = 'external call' > 
value = 'None' > 

» 




CC-INFO 




« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01' H> 

< id type/subtype = 'Call status', value = 'CS call hold' > 

» 


Call id assignement and 
line selection by the FP 


CC-INFO 




« CALL-INFORMATION, 


Line selection performed 
by the FP 


< id type = 'Line identifier', subtype = 'external call', value = 'u' > 

< id type = 'Line identifier', subtype = 'line type information', 




value = 'xy'B > 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 

< id type/subtype = 'Call status', value = 'CS call proc' > 











Figure C.12: Outgoing parallel calls: all in one PP message, FP managed line selection 
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C.4.1 .3 Line pre-selection by PP - Manual dialling of called number 

Use case: The PP initiates a parallel call with '1C15'H / 17'H + line-id in a single {CC-INFO} message (e.g. the user 
pre-selected - with a GAP or Part 1 PP - or pre-dialled ('#k') the line to use, unless the PP is attached to only one line, in 
which case the user does not have to do so, but the present use case still applies, before manually dialling the called 
number). The FP replies with the call-id as soon as it received the first message, and before dialling of the called 
number. 




Outgoing call initiation with Line selection by the PP (not FP-managed) 



Line selected for the call (if external) 
by an NG-DECT Part 3 PP using the 
CALL-INFO method 



Line selected for the call (if external) 
by a GAP or NG-DECT part 1 PP 
using the KEYPAD method 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = '1C15'H/'17'H + 'called number' > >:» 
« CALL-INFORMATION, 
< id type = 'Line identifier', subtype = 'external call', value = 'u' > » 

CC-INFO 



« MULTI-KEYPAD, < Keypad info ■■ 
'called number' > 



'1C15'H/'17'H + '23 3u'H + 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01' H> 

< id type/subtype = 'Call status', value = 'CS call hold' > 



Call id assignement by the FP 



Line identifier is only sent to NG- 
DECT Part 3 PPs 



CC-INFO 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value = 'u' > 

< id type = 'Line identifier', subtype = 'line type information', 

value = 'xy'B > 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call setup ack' > 



CC-INFO 

► 

« MULTI-KEYPAD, < Keypad info = 'called number' > » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

» 



Figure C.13: Outgoing parallel calls: line pre-selection by PP, Manual dialling of called number 
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C.4.1 .4 FP-managed line selection - Manual dialling of called number 

Use case: The PP initiates a parallel call with '1C15'H / 17'H (e.g. the user pressed the R/INT key before manually 
dialling the called number). The FP replies with the call-id as soon as it received the first message (however preceded 
by the 'CS call hold' call status for the first call), and before dialling of the called number. When sending the call-id, the 
FP cannot send the line-id together with it (because FP does not know at this stage if PP will use FP-managed line 
selection). 

NOTE: This use case is listed here as a reminder, as it is already presented as a mainstream use case in the 
"Outgoing parallel call initiation" procedure (see clause 7.4.3.5.1, figure 5). 

C.4.1 .5 Unsupported new outgoing parallel call 

Use case: The PP initiated an outgoing parallel call (external or internal) at a point in time where the FP and/or the line 
cannot support the additional call. A "busy system or line notification" (see clause 7.4.8.3) is sent to the PP. If a call id 
was assigned to the new call (a call context was created on FP side and the call id was notified to the PP), a "call 
release" should also be sent. 
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Ongoing call (external or internal) , call id = 1 




Outgoing call initiation including line selection by the PP (not FP-managed) 



Line selected for the call (if 
external) by an NG-DECT Part 3 
PPusing the CALL-INFO 
| method 

OR 

Line selected for the call (if 
external) by a GAP or NG- 
DECT Part 1 PP using the 
KEYPAD method 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = '1C15' / '17'H + 'called number' > » 

« CALL-INFORMATION, 
< id type = 'Line identifier', subtype = 'external call', value = 'u' > » 

CC-INFO 



« MULTI-KEYPAD, < Keypad info = '1 C1 5' / '1 7'H + '23 3u'H + 'called number' > 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call hold' > 



Busy system : assign call id anyway (if 
not already done) and release the call 



Line identifier is only sent to 
NG-DECT Part 3 PPs 



Call id assignment 

CC-INFO 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value = 'u' > 

< id type = 'Line identifier', subtype = 'line type information', value = 'xy'B > 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call proc' > 



Busy system and call release 

CC-INFO 



If required by the 'Tones provision' feature « SIGNAL value = 'busy tone' = '04'H » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS call disconnecting' > 

< id type = 'Call status', subtype = 'Call status reason' value = 'system busy' > 
» 

CC-INFO After some time out 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS idle' : 



Return to previous call 

CC-INFO 



« MULTI-KEYPAD, < Keypad info = '1 C42'H > » 

« CALL-INFORMATION, 
< id type/subtype = 'Call identifier', value = '01 'H > » 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '01 'H > 

< id type/subtype = 'Call status', value = 'CS call connect' > 



Figure C.14: Outgoing parallel calls: unsupported new outgoing parallel call 
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C.4.2 Incoming parallel calls 



C.4.2.1 Two simultaneous incoming calls on two different lines 

Use case: the PP is attached to several lines. An incoming call is received on two different lines. This use case shows 
that from the PP point of view, this use case does not fundamentally differ from the use case where two simultaneous 
calls occur on a single line. 



PP 

attached at least to 
two lines u and v 



FP 



Network 



CC-SETUP 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number 1' > » 

« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > » 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information' > 

< Identifier value = 'xy'B > 

< id type/subtype = 'Call identifier' value = 'call-id 1'> 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 

CC-INFO 



« SIGNAL value = 'call waiting tone' = '07'H » 

« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number 2' > » 




Incoming call to line u 
from 'calling number 1' 




Incoming call to line v 
from 'calling number 2' 



If required by the Tones 
provision' feature 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = v > » 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'line type information' > 

< Identifier value = 'xy'B > 

< id type/subtype = 'Call identifier' value = 'call-id 2' > 

< id type/subtype = 'Call status', value = 'CS call setup' > 



Figure C.15: Incoming parallel calls: two simultaneous incoming calls on two different lines 



ETSI 



307 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



C.4.2.2 FP release of waiting call when remote party hangs up 

Use case: use of call release from the FP when the remote party hangs up, occurring even before the PP answered the 
call; in that case there is no need for a 'CS call connect' call status for the first call which was not disconnected (waiting 
call not answered). 



PP2 

attached to line u 



FP 



Network 




CW tone 
heared by user 



Line on which waiting call 
occurred if external 



CW context 
created 



CW context 
deleted 



Call established with call id 1 (external or internal) 



CC-INFO 




« SIGNAL value = 'call waiting tone' = '07'H » If required by the Tones 

provision' feature 

« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Line identifier', subtype = line type information', 

value = 'xy'B > 

< id type/subtype = 'Call identifier, 

value = 'waiting call id' = call id 2 > 

< id type/subtype = 'Call status', value = 'CS call setup' > 

» 



Call release of the (non answered) waiting call 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = 'call id 2' > 

< id type/subtype = 'Call status', value = 'CS idle' > 

» 




Call established with call id 1 continues 



remote party 
hangs up 




Figure C.16: Incoming parallel calls: FP release of waiting call when remote party hangs up 



NOTE: There is no need here for a 'CS call connect' for the first call because the call waiting was not yet 
accepted. 
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C.4.2.3 Two incoming calls before user answers 

Use case: Two calls are arriving before the user answers any of them. Both calls are presented to the user on the MMI 
and the user selects one of them. 

For this revision of the present document, the FP blocks the second incoming call presentation until the first call 
presentation is terminated (i.e. until this first call is accepted or released). 

NOTE: Other more advanced behaviours are left for further study. 



PP1 

attached to lines u and v 
(v may be equal to u) 



FP 



Network 



Line on which waiting call 
occurred if external 



If call with call-id 1 is 
accepted bv the user 



CW tone 
heared by user 



Line on which waiting call 
occurred if external 



CC-SETUP 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'u' > 

< id type = 'Line identifier', subtype = 'line type information', valile = 'xy'B > 

< id type/subtype = 'Call identifier', value = 'waiting call id' = cal id 1 > 

< id type/subtype = 'Call status', value = 'CS call setup'> 

» 

CC-ALERTING 



First incoming 
call (call id 1) 



CC-CONNECT 



CC-CONNECT-ACK 



CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', 
value = 'waiting call id' = call id 1 > 

< id type/subtype = 'Call status', value = 'CS call connects 



Call waiting indication (call-id 2) is deferred until first call 
presentation is terminated (call accepted or released) 

CC-INFO 




2" Incoming call 
arrives on FP side 



« SIGNAL value = 'call waiting tone' = '07'H » 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = V > 

< id type = 'Line identifier', subtype = 'line type information', valpe 

< id type/subtype = 'Call identifier', 
value = 'waiting call id' = call id 2 > 

< id type/subtype = 'Call status', value = 'CS call setup'> 



If required by the Tones 
provision' feature 



'xy'B > 



Figure C.17: Incoming parallel calls: Two incoming calls before user answers 
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C.4.3 Call waiting represented as first call when user hangs up 

Use case: the PP is attached to a multi-call line. A call is on going from PPL A second incoming call is presented to the 
line. The PP hangs up and the call is represented as a first incoming call. 



PP 

attached to 
multiple-call line u 



FP 



Network 



Call waiting 
indication 



User 
hangs up 

Incoming call 
presentation 




Call established with call id 1 (externa 



CC-INFO 



or internal) 





Incoming call from 
'calling number' 



« SIGNAL value = 'call waiting tone' = '07'H » If required by the Tones 

provision' feature 

« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value 

< id type = 'Line identifier', subtype = line type information 
<id type/subtype = 'Call identifier' value = 'call id 2' > 
<id type/subtype = 'Call status' value = 'CS call setup' > 

CC-RELEASE 



CC-RELEASE-COM 



CC-SETUP 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value 

< id type = 'Line identifier', subtype = line type information', 

< id type/subtype = 'Call identifier' value = 'call id 2' > 
<id type/subtype = 'Call status' value = 'CS call setup' > 



u > 

, value = 'xy'B > 



u > 

value = 'xy'B > 



NOTE: The «CALL-INFORMATION» information element is not sent in a CC-RELEASE or CC-RELEASE-COM 
message. 

Figure C.18: Call waiting represented as first call when user hangs up 



C.5 List access service use case examples 



C.5.1 General 



In the following clauses, several use case examples for list access are depicted. 

It has to be noted that the sequences are only examples, it cannot be mandatory that the message flows are always 
exactly in the described way. However it is recommended to follow the examples where possible in order to ensure 
interoperability. 

For clarity of the following flowcharts, «Call information» IE including call identifiers and line identifiers does not 
appear in some of the CC messages that convey it. Please note that they should not be omitted when implementing 
equivalent cases. 
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.5.2 Use case: transfer number from Missed Calls List to 
Contact List 



PT 



FT 



user starts missed call list 



CC-Setup 



IE « BASIC_SERVICE < Call Class=LiA service call setup > » 
CC-Call-Proc 



IWU-lnfo 



IE « IWU to IWU= start session , missed call list, Nb sorting field 
identifiers=0 » 



IWU-lnfo 



IE « IWU to IWU= start session confirm, session identifiers , Total number, 
Sorting field identifier 1=date and time » 



IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 

IWU-lnfo 



IE « IWU to IWU= read entries confirm, session id, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part i » 



user selects entry to save in contact list 



IWU-lnfo 



IE « IWU to IWU= start session, contact list, Nb sorting field identifiers=0 » 



IWU-lnfo 



IE « IWU to IWU= start session confirm, session identifier=2, Total number, Sorting 
field identifier! =name, Sortina field identifier2=First name » 



Figure C.19: List access use case: transfer number from Missed Calls List to Contact List (1/2) 
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PT 



FT 



IWU-lnfo 



IE « IWU to IWU= save entry, session id=2, entry identifier=00H » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id=2, content part 1 



IWU-lnfo 

IE « IWU to IWU= data packet last, session id=2, content part j » 



IWU-lnfo 



IE « IWU to IWU= save entry confirm, session id=2, position index, entry 

identifier =xxH » 



IWU-lnfo 



IE « IWU to IWU= end session, session identifiers » 
IWU-lnfo 

IE « IWU to IWU= end session confirm, session identifier^ » 



IWU-lnfo 



IE « IWU to IWU= end session, session identifier=2 » 
IWU-lnfo 

IE « IWU to IWU= end session confirm, session identifiers » 



CC-RELEASE 



CC-RELEASE-COM 



Figure C.20: List access use case: transfer number from Missed Calls List to Contact List (2/2) 



The second session might also be established after release of the first session. FP should be capable to handle at least 
two sessions independently. 
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C.5.3 Use case: select and call internal party 



PT 



FT 



Direct PT initiated link establishment 



CC-Setup 



IE « BASIC_SERVICE <Call Class= LiA service call setup> » 
CC-Call-Proc 



IWU-lnfo 



IE « IWU to IWU= start session, internal names list, Sorting field 
identifierl =number » 

IWU-lnfo 



IE « IWU to IWU= start session confirm, session identifier, Total number, 
Sorting field identifierl =number » 

IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 



IWU-lnfo 



IE « IWU to IWU= read entries confirm, session id, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 

IWU-lnfo 



IE « IWU to IWU= end session, session identifier » 



IWU-lnfo 



IE « IWU to IWU= end session confirm, session identifier » 



CC-lnfo 



IE « MULTI-KEYPAD, int-key + number digits » 



Figure C.21 : List access use case: select and call internal party 

The int-key is necessary at least if the basic service is not internal call. 
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C.5.4 Use case: select and call number from Contact List 



PTs 



FT 



Direct PT initiated link establishment 



CC-Setup 



IE « BASIC_SERVICE < Call Class= LiA service call setup > » 
CC-Call-Proc 



IWU-lnfo 



IE « IWU to IWU= start session, contact list, Nb sorting field identifiers » 



IWU-lnfo 



E « IWU to IWU= start session confirm, session identifier, Total number, Sorting 
field identifier"! =name Sorting field identifier2= first name » 

IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 



IWU-lnfo 



IE « IWU to IWU= read entries confirm, session id, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 

IWU-lnfo 



IE « IWU to IWU= end session, session identifier » 



IWU-lnfo 



IE « IWU to IWU= end session confirm, session identifier » 



CC-lnfo 



IE« MULTI-KEYPAD, 1CH 1 5H + number digits » 



Figure C.22: List access use case: select and call number from Contact List 
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C.5.5 Use case: save entry with invalid format 



PT FT 










list access session setup 






IWU-lnfo 




► 

IE « IWU to IWU= save entry, session id, entry identifier » 

IWU-lnfo 


► 

IE « IWU to IWU= data packet, session id, content part 1 (invalid entry format) » 

IWU-lnfo 


IE « IWU to IWU= data packet last, session id, content part m (entry format 

incorrect) » 

IWU-lnfo 


< 

IE « IWU to IWU= negative acknowledgement, session id, reject reason=entry 

format incorrect » 



Figure C.23: List access use case: save entry with invalid format 

NOTE: As described in clause 7.4.10.4.9, the negative acknowledgement is sent after the 'data packet last' 
information is received from the PP. 
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C.5.6 Use case: read invalid start index 



PT FT 










list access session setup 






IWU-lnfo 




► 

IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 

IWU-lnfo 


4 

IE « IWU to IWU= negative acknowledgement, session id, reject 
reason=invalid start index » 



Figure C.24: List access use case: read invalid start index 
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C.5.7 Use case: modify a PP internal name 

The user edits the internal name of the PP number '3' in the DECT system. This use case can be used just after 
subscription registration or later. 



PP FP 











Internal names list access start session 






IWI l-INFO 

I V V U 1 1 M 1 W 




> 

IE « IWU to IWU=search entries, session id, matching option=00H, 
searched value = 33H, counter=1 , list of field identi fiers= Number id, Name id » 

II I | 1 1 |M 1 — /-v 

IWU-INFO 


< 

IE « IWU to IWU=search entries confirm, session id, start index, counter=1 » 

IWU-INFO 


< 

IE « IWU to IWU=data packet last, session id, content part=(entry 
identifier, number, name) for 3 rd entry » 

IWU-INFO 


> 

IE « IWU to IWU=edit entry, session id, entry identifier, list of field 
identifiers^ number id, name id » 

IWU-INFO 


-< 

IE « IWU to IWU=edit entry confirm, session id, start index » 

IWU-INFO 


IE « WU to IWU=data packet last, session id, content part= ontent part= 
(entry identifier, number, name) for 3 rd entry » 




user updates the 'name' field for 3 rd entry in internal name list 






IWI l-INFO 

IWU 1 1 N 1 V- ' 

► 




IE « IWU to IWU=save entry, session id, entry identifier » 
IWU-INFO 


F3 ► 

IE « IWU to IWU=data packet last, session id, content part = 3 
entry content updated » 

IWU-INFO 


< 

IE « IWU to IWU=save entry confirm, session id, entry identifier, start index » 




Internal names list access end session 












FP notifies PP 3 of the changing of its name using clause 7.4.1 0.2 











Figure C.25: List access use case: modify a PP internal name 
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C.5.8 Use case: entry distributed over two data packets 

Read the Missed Calls List, the number of requested entries is 1 with all possible fields. The first entry in the list is the 
following: 

• CLIP= "0674011776" 

• CNIP = "J.Rene BIDA" 

• 8 calls received 

• Last call received on 17/03/09 at 12 h 07 mn 08 s 

The data content of this entry exceeds the 56 octets limit, so the entry is sent over two data packets: one "data packet" 
command followed by one "data packet last" command. Each data packet is sent in a separate IWU-INFO «IWU to 
IWU» message as defined in tables C.6 and C.7. 



Table C.6: Example of one entry sent over two 'Data packet' commands - 1 st «IWU to IWU» 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<l_ength of content> 


3BH 


Length of content 




<Protocol Discriminated 


03H 


List access 




<Command> 


13H 


Data packet 




<Session identifier 


81H 


Session identifier (session id=1) 




<Entry identifier for 1 st entry> 


81 H 


Identifier of the entry (entry =01 H) 




<Entry length> 




Lengin (iengin=oL>n) 




<Entry field identifier 1 > 


Ul n 


Field identifier = Number 




•ctniry neio iengin> 


QDU 

oBn 


Lengin (iengin=ut>n) 




<tmry neio conteni u> 


onu 
oUn 


rropeny (eciiiaDie=u, own=u, ini=uj 






oUn 


Digit (1 ) = u 






oon 


Digit (d) = b 






o/n 


Digit (o) = / 






34H 


Digit (4) = 4' 






30H 


Digit (5) = '0' 






31 H 


l-V ■ 'i / A\ 1-4 1 

Digit (6) = '1' 






31 H 


Digit (7) = '1' 






37H 


Digit (8) = T 






37H 


Digit (9) = 7 




<Entry field content j> 


36H 


Digit (10) = '6' 




<Entry field identifier 2> 


02H 


Field identifier = Name 




<Entry field length> 


8DH 


Length (length=0DH) 




<Entry field content 0> 


80H 


Property (editable=0) 






4AH 


Character (1) = 'J' 






2AH 


Character (2) = '.' 






52H 


Character (3) = 'R' 






62H 


Character (4) = 'e' 






6EH 


Character (5) = 'n' 






C3H 


Character (6) = 'A' 






A9H 


Character (7) = '©' => 'e' 






20H 


Character (8) = " 






42H 


Character (9) = 'B' 






49H 


Character (10) = T 






44H 


Character (11) = 'D* 




<Entry field content k> 


41 H 


Character (1 2) = 'A' 




<Entry field identifier 3> 


03H 


Field identifier = Date and Time 




<Entry field length> 


88H 


Length (length=08H) 




<Entry field content 0> 


80H 


Property (editable=0) 






C0H 


Coding= Time and Date 
Interpretation = The current 
time/date 






09H 


Year = 2009 






03H 


Month = March 






17H 


Day = 1 7 
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Information olomont 

1 1 1 1 Ul 1 1 IdllUI 1 CldlldlL 


Fiolrl u/ithin tho information 
nciu v v ill ill i nit; ii i 1 1 idiiui i 


Qtanrlai*H \/aliioc 
OLallUalU ValUCo 


Normative aotion/oommont 

1 1 Id LI VC dlsLIUII/lsUlllllld 11 




plpmpnt 

1 V> III Tm* III 


within thp fipld/IE 

Will III 1 III 1 1 \^ IM' 1 




«IWU to IWU» 




12H 


Hour = 12 






07H 


Mini itp — 7 

1 VI 1 1 IU LCi — / 






08H 


Qppnnrl — ft 




<"Fntr\/ fiplrl cnntpnt Is 

si iiLiy i i^iu uU 1 1 iui ii i 


00H 


Timp 7nnp — -i-0 
1 1 1 1 1 \j \ \j — i \j 




•tf'Fntrv fipld irlpntifipr 4~> 

l_ 1 1 L 1 y 1 1 \j 1 \A 1 U \j 1 1 L 1 1 1 1 r ^ 


04H 


Fiplrl irlpntifipr — Npw 




<"Fntrv fiplrl Ipnnth^ 

si iiLiy i iciu ici iuli 


81 H 


1 pnnth npnnth— 1^ 




<"Fntr\/ fiplrl nnntpnt 0^ 

si — liny i uui i ici i L yj*-* 


A0H 


Prnnprtv fprlitphlp— 0, npw— "H 
i iu|^oiLy ^cui iciuic — \j j i ic vv — i j 




<"Fntrv fiplrl irlpntifipr 

si i ili y 1 1 d "lJ i i i li i ic i \j «-* 


05H 


Fiplrl irlpntifipr — 1 inp namp 

1 ICIU lUCIILIIId — l—IIIC lldlllC 




•^Fntrv fiplrl lpnnth"> 

s i— _ i i l i y ii w iu i^i iuu i ^ 


87H 


1 pnnth 

1 — \j \ IULI 1 




<"Fntr\/ fiplrl rontpnt 0^ 

SI 1 ILI V 1 ICI \J uwl 1 ICI 1 L v_/>* 


80H 


Prnnprtv ('prlitahlp— (W 






56H 


Character Ml - 'V 

W 1 ICll ClLrLd \ ' / — » 






6FH 


Character i?\ - 'r>' 






49H 


Character C31 - T 

V-/I lul uwlvl \\J 1 — 1 






50H 


Character (4) = 'P' 






20H 


Character (5) = " 




<Entry field content m> 


31 H 


Character (6) = '1' 




<Entry field identifier 6> 


06H 


Field identifier = Line id 




<Entry field length> 


82H 


Length 




<Entry field content 0> 


80H 


Property (editable=0) 


Table C.7: Example of one entry sent over two 'Data packet' commands - 2 nd «IWU to IWU» 


Information element 


Field within the information 


Standard values 


Normative action/comment 




element 


within the field/IE 




«IWU to IWU» 


<Length of content> 


08H 


Length of content 




<Protocol Discriminator 


03H 


List access 




<Command> 


14H 


Data packet last 




<Session identifiers- 


81H 


Session identifier (session id=1) 




<Entry field content n> 


81H 


Identifier value = 01 H 




<Entry field identifier 7> 


07H 


Field identifier = Number of calls 




<Entry field length> 


82H 


Length 




<Entry field content 0> 


80H 


Property (editable=0) 




<Entry field content p> 


08H 


value = 8 calls 



C.5.9 Use case: user aborting the edition of an entry 

If the previously started edit procedure has to be terminated without any change on the list entry, PP should perform the 
'save entry' procedure with 'save entry' command followed by only one empty 'last data packet' as defined in the two 
tables C.8 and C.9. 

NOTE: This is not considered as an error case and a regular 'save entry confirm' is used (no negative 
acknowledgement is used). 



Table C.8: Example of one save without changing the list entry - 1 st «IWU to IWU» 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


04H 


Length of content 


<Protocol Discriminated 


03H 


List access 


<Command> 


0AH 


Save entry 


<Session identifier 


82H 


Session identifier (session id=2) 


<Entry identifier for 1 st entry> 


83H 


Identifier of the entry (entry =03H) 
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Table C.9: Example of one save without changing the list entry - 2 nd «IWU to IWU» 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


03H 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command> 


14H 


Data packet last 


<Session identifier 


82H 


Session identifier (session id=2) 



C.6 List access service with voice calls (additional use 
cases and procedure diagrams) 

C.6.1 General 

In the following clauses, several procedure diagrams for list access service combined with voice calls are depicted. 

It has to be noted that the sequences are only examples, it cannot be mandatory that the message flows are always 
exactly in the described way. However it is recommended to follow the examples where possible in order to ensure 
interoperability. 

C.6. 2 List access when a voice call is already ongoing 

Please note that for clarity of the flowcharts, the line identifier is not mentioned. However it has to be implemented and 
managed correctly as defined by the present document. 

C.6. 2.1 Use case: Consult a list during a voice call 

Use case: Look for the number of a contact while you are in voice call and then come back to the voice call. 
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PP FP 





<^^^ "" 1 Ongoing call 1 (external or internal) with call-id 1 ' ~~~^^^^> 






Put call 1 on hold (mandatory only if Cf channel used for list access, optional otherwise) 




r 


CC-INFO 




; 




> 

<< MUL 1 1-rS.b Y rAU, IflTO = 11/41 n » 

« CALL-INFORMATION, Line Id, 'call-id 1' > 


• 




Access contact list (within call 1) 






IWU-INFO 

w 






w 

« IWU-TO-IWU <Command = start session>, <List identifier = contact list> » 






IWU-INFO 






* 

« IWU-TO-IWU <Command = end session confirm>, <session identifier » 






Resume call 1 (mandatory only if Cf channel used for list access, optional otherwise) 




r 


CC-INFO 






1 

« MULTI-KEYPAD, info = '1 C 42'H » 

« CALL-INFORMATION, Line Id, 'call-id 1' > 


- 




Back t0 ongoing call 1 (external or internal) ' 





Figure C.26: List access use case: consult a list during a voice call 



C.6.2.2 Use case: call transfer using Internal Names List (first call explicitly- 
put on hold) 

Use case: Ongoing call is put on hold before establishing a parallel internal call using the Internal Names List. The first 
call is then transferred. It shows in particular that a call can optional be put on hold before an outgoing second call is 
made. In this case, it is proposed that an additional call id is attached to the list access. 

NOTE: The list access re-uses call idl. 
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PP FP 





Ongoing call 1 (external or internal) with call-id 1 
Put call 1 on hold 




I 

j 


CC-INFO 


■ 


» 

« MULTI-KEYPAD, info = '1 C 41 'H » 

« CALL-INFORMATION, Line Id, 'call-id 1' > 
CC-INFO 


< 

« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = call id 1 > 
id type/subtype = 'call status', value='CS call hold' > » 




Access internal names list to find call transfer target (within call 1) 






l\A/l I IMCn 
IVV U-IINrVJ 




; ► 

« IWU-TO-IWU <Command = start session>, <List identifier = internal names list> » 

IWU-INFO 


< 

« IWU-TO-IWU <Command = end session confirm>, <session identifier » 




Establish parallel internal call 2 






CC-INFO 

► 




« MULTI-KEYPAD, 17H + terminal id number » 

CC-INFO Call id assignment by the FP 


« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = 'call id 2' > 
id type/subtype = 'call status', value='CS call proc'> » 




Call transfer request 






CC-INFO 




► 

« MULTI-KEYPAD, info = '1C 34'H » 
Only if the PP « CALL-INFORMATION, 
implements < 'dentifier type = 'Call identifier' > 
the "Call < dentifier subtype = 'Call identifier' > 
identification" feature < Identifier value = 'call-id 1 ' > 

» 



Figure C.27: List access use case: call transfer using Internal Names List 
(first call explicitly put on hold) 



C.6.2.3 Use case: call transfer using Internal Names List (first call implicitly 
put on hold by internal call) 

Use case: Ongoing call is implicitly put on hold before establishing a parallel internal call using the Internal Names 
List. The first call is then transferred. It shows in particular that the T7'H implicitly puts the ongoing call on hold. 

NOTE: The list access re-uses call id2. 
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PP FP 





<^^^ Ongoing call (external or internal) with call-id 1 

Request internal call, call 1 implicitely put on hold 






CC-INFO 




► 

« MULTI-KEYPAD, 17H » 

« CALL-INFORMATION, Line Id, 'call-id 1' » 
CC-INFO 


< 

« OAI I -INFORMATION < id tvnp/quhtvnp - 'Call iripntifipr' valnp - rail id 1 i> 

id type/subtype = 'call status', value='CS call hold' > » 
CC-INFO 


< 

« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = call id 2 > 
id type/subtype = 'call status', value='CS call setup ack'> » 




Access internal names list to find call transfer target (within call id 2) 






IWU-INFO 




► 

« IWU-TO-IWU <Command = start session>, <List identifier = internal names list> » 

IWU-INFO 

« IWU-TO-IWU <Command = end session confirm>, <session identifier » 


< 




tsTauiisn parallel internal can c. 






CC-INFO 




► 

« MULTI-KEYPAD, Called nb = terminal id number » (call-id=2) 

CC-INFO 


< 

« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = call id 2 > 
id type/subtype = 'call status', value='CS call proc'> » 




Call transfer request 






CC-INFO 

« MULTI-KEYPAD, info = '1C 34'H » 
Only if the PP « CALL-INFORMATION, 
implements < Identifier type = 'Call identifier' > 
the "Call < Identifier subtype = 'Call identifier' > 
identification" feature < Identifier value = 'call-id 1 ' > 
» 






Figure C.28: List access use case: call transfer using Internal Names List 
(first call explicitly put on hold) 
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C.6.2.4 Use case: establishing a parallel call using Contact List 

Use case: During an ongoing call, the user establishes a parallel external call using the Contact List. In this case, there is 
no need for an additional call id for the list access: it is done within existing call. 



p 


3 FF 

<C^^]^^ Ongoing call (external or internal) on call id 1 '^"^ 

Put call 1 on hold 


> 




CC-INFO 


---i 


■ 


► 

« MULTI-KEYPAD, info = '1C 41 'H » 

« CALL-INFORMATION, Line Id, 'call-id 1' » 
CC-INFO 


• 

« CALL-INFORMATION, Line Id, 'call-id 1' , call status = 'CS call hold' » 




Access contact list to find a contact (within call id 1) 






IWU-INFO 




: : — : — ~ : * 

<< ivvu- 1 u-ivvu <L*ommanu = sian session>, <List lueniiTier =coniact msi> » 

l\A/l 1 IMCr* 

« IWU-TO-IWU <Command = end session confirm>, <session identifier » 


4 




Try to establish parallel external call 2 

CC-INFO 




► 

« MULTI-KEYPAD, '1C15'H + external number » (call-id 1) 

CC-INFO 


« CALL-INFORMATION, Line Id, 'call id 2, call status='CS call proc'> » 

Parallel external call establish on call id2 ^^^^^ 



Figure C.29: List access use case: establishing a parallel call using Contact List 
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C.7 DECT system settings diagrams 



C.7.1 



General 



In the following flowcharts, we assume that: 

• N lines are defined, i.e. 'Total number of entries' = N in Line Settings List before starting lines settings session. 

• The total number of registered PPs is M, i.e. 'Total number of entries' = M in Internal Names List before 
starting internal names session. 

• Only one data packet command is necessary to read one entry content, i.e. 'data packet last' command is 
received directly. 

• The fields are not PIN protected (except when stated otherwise). 

NOTE: In the following flowcharts, the read entries or search entries might be done prior to the sequence (in a 
previous session for example). But this is not the most usual behaviour as the PP may probably show the 
current value of the setting before enabling the user to modify it. 

For clarity of the following flowcharts the «Call information» IE including call identifier does not appear in the CC 
messages that convey it. Please note that it should not be omitted when implementing equivalent cases. For example the 
call identifier is assigned by the FP after {CC-SETUP} message. 

In the following use cases, it is assumed that "Early encryption" feature [GAP.M.15] is not implemented. In the 
flowcharts, the encryption is started by the FP systematically after the list access call setup. However, some 
implementation flexibility is allowed concerning the point in time when link is encrypted as long as: 

• PIN code exchange is done over an encrypted link (see clause 7.4.1 1.1). 

• List access service call gets finally encrypted at some point in time. See [GAP.N.35] feature, encryption of all 
calls procedure (see clause 8.45.1 of [12]). 



C.7 



2 Modifying the PIN code 



Use case: FP without keyboard, the user modifies the system PIN code from the PP. 
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PP 



FP 



CC-SETUP 



« BASIC SERVICE <Call Class=LiA service call setUD> » 
CIPHER-REQUEST 



Encrypted 



CC-CALL-PROC 



IWU-INFO 



IE 



«IWU to IWU= start session, DECT system settings list, Number of sorting fields 



IWU-INFO 



0» 



IE «IWU to IWU= start session confirm, session identifier, Total number=1 > 



Read Current 



'IN code: 



IWU-INFO 



IE «IWU to IWU= read entries, session id, start index =1 , counter=01 H, 
list of field identifiers= Current PIN code, FP version » 

IWU-INFO 



IE «IWU to IWU= read entries confirm, session id, start index, counter=1 » 

IWU-INFO 



IE «IWU to IWU= data packet, session id, content part » 
(FFH FFH FFH FFH) 

IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part » 



IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifiers= Current PIN code » 

IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part= (entry identifier, 
Current PIN code) > (FFH FFH FFH FFH) 



Save Current 'IN code 



User enters current PIN code 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier» 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part = current PIN code>: • 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, start index» 



FP checks if PIN code entered by the user matches current system PIN 



Figure C.30: Modifying the PIN code (1/2) 
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PP 



FP 



Encrypted 



: entered PIN 



ode matches current system PIN 



IWU-INFO 



IE «IWU to IWU= read entries, session id, start index =1 , counter=01 H, 
list of field identifiers= New PIN code, FP version » 

IWU-INFO 



IE «IWU to IWU= read entries confirm, session id, start index, counter=1 

IWU-INFO 



IE «IWU to IWU= data packet, session id, content part » 
(FFH FFH FFH FFH) 

IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part » 



IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifi gts= Ngw PIN codG >> 

IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start inde 

IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part= (entry identifier, 
New PIN code (FFH FFH FFH FFH) > 



New PIN code is entered twice. If equal, PP saves the new PIN code value 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier» 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part = New PIN code» 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, start index» 



DECT system settings end session 



Figure C.31 : Modifying the PIN code (2/2) 
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C.7.3 Resetting the base 

Use case: Reset all DECT system and line settings to their default value. 



PP 

_L_ 



FP 
J 



DECT system settings start session (on encrypted link) 



Read DECT 



system settings: 



IWU-INFO 



IE «IWU to IWU= read entries, session id, start index =1 , counter=01 H, 
list of field identifiers= Current PIN code, FP version » 

IWU-INFO 



IE «IWU to IWU= read entries confirm, session id, start index, counter=1» 

IWU-INFO 



IE «IWU to IWU= data packet, session id, content part » 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part » 



IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifier Base reset » 

IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 

IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part= (entry identifier, 

Base reset) > 



User confirms system and line settings reset 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier» 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part = (Base reset, YES) >j> 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, position 
index, total number of available entries » 



DECT system settings end session 



Figure C.32: Resetting the base 



C.7.4 Resetting the base (PIN code protected field) 



Use case: the use case is the same as the previous one except that the 'Base reset' field is PIN code protected. 
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PP 



FP 
I 



DECT system settings start session (on encrypted link) 



Read DECT 



system settings: 



IWU-INFO 



IE «IWU to IWU= read entries, session id, start index =1 , counter=01 H, 
list of field identifiers= Current PIN code, FP version » 

IWU-INFO 



IE «IWU to IWU= read entries confirm, session id, start index, counter=1» 

IWU-INFO 



IE «IWU to IWU= data packet, session id, content part » 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part » 



PIN code ch :cking: might be done at any time during the LiA service call (here or before) 



Edit and save the current PIN code 



FP checks if PIN code entered by the user matches current system PIN 



If entered PIN code matches current system PIN 

IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifiers= Base reset » 

IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 

IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part= (entry identifier, 

Base reset) > 



User confirms system and line settings reset 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier» 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part = (Base reset, YES) 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, position 
index, total number of available entries » 



DECT system settings end session 



Figure C.33: Resetting the base (PIN protected field) 



ETSI 



329 



ETSI TS 102 527-3 V1.5.1 (2013-03) 



C.8 Line settings diagrams 
C.8.1 General 

In the following flowcharts, we assume that: 

• N lines are defined, i.e. 'Total number of entries' = N in the Line Settings List before starting lines settings 
session. 

• Only one data packet command is necessary to read one entry content, i.e. 'data packet last' command received 
directly. 

In the following flowcharts, the read entries or search entries might be done prior to the sequence (in a previous session 
for example). But this is not the most usual behaviour as the PP may probably show the current value of the setting 
before enabling the user to modify it. 

For clarity of the following flowcharts the «Call information» IE including call identifier does not appear in the CC 
messages that convey it. Please note that it should not be omitted when implementing equivalent cases. For example the 
call identifier is assigned by the FP after {CC-SETUP} message. 

In the following use cases, it is assumed the link encryption is started by the FP at list access call setup although not 
always depicted in the flowcharts. As explained in clause C.7.1, some flexibility is allowed concerning this 
implementation choice. 

C.8. 2 Changing the settings of a line 

Use case 1 : The user edit the line settings of the line number 'i'. Read only the selected entry. 
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PP 



FP 



CC-SETUP 



« BASIC_SERVICE <Call Class=LiA service call setup> » 
CC-CALL-PROC 



IWU-INFO 



IE «IWU to IWU= start session, lines settings, Number of sorting fields =0 » 

IWU-INFO 

^E «IWU to IWU= start session confirm, session identifier, total number=N » 



Line i selectee by the user (i e 1 .. N): 



IWU-INFO 



IE «IWU to IWU= read entries, session id, start index =i, counter=01 H, 
list of field identifiers= Line id id, Line name id, Multiple calls mode id » 

IWU-INFO 



IE «IWU to IWU= read entries confirm, session id, start index, counter=1» 

IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part for i entry» 

IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifiers= Line id id, Line name id, Multiple calls mode id» 

IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 

IWU-INFO 



IE 



«IWU to IWU= data packet last, session id, content part= content part for i tn entry: 



User updates the settings for i line in line settings list 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier » 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part= i entry updated : 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, position index, 
total number of available entries » 

IWU-INFO 



IE «IWU to IWU= end session, session identifier» 
IWU-INFO 



IE «IWU to IWU= end session confirm, session identifier » 

FACILITY 



«EVENTS NOTIFICATIONS, <List change indication, Line settings, 
N> > « CALL-INFORMATION, Lineld » 

CC-RELEASE 



CC-RELEASE-COM 



FP notifies all 
PP attached 
to the line 



Figure C.34: Changing the settings of a line (use case 1) 

Use case 2: The user edit the line settings of the line number 'i'. Read all N entries before editing the selected entry. 
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PP FP 





CC-SETUP 




« BASIC_SERVICE <Call Class=LiA Service call setup> » 
CC-CALL-PROC 


IWU-INFO 


w 

IE «IWU to IWU= start session, lines settings, Number of sorting fields =0 » 

IWU-INFO 


^E «IWU to IWU= start session confirm, session identifier, total number=N » 

IWU-INFO 


► 

IE «IWU to IWU= read entries, session id, start index =i, counter=N, 

MSt OT TIGIQ IQGnTITIGrS= LlnG 10 10, LlnG narnG 10, IVIUItlplG Calls mOOG 10 >> 

IWU-INFO 


4 

IE «IWU to IWU= read entries confirm, session id, start index, counter=N» 

IWU-INFO 


< 

IE «IWU to IWU= data packet, session id, content part » 

IWU-INFO 


4 

IE «IWU to IWU= data packet last, session id, content part » 


Line i selectee 
IE 


by the user (i e 1 .. N): IWU-INFO 


>> 


► 

IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifiers= Line id id, Line name id, Multiple calls mode id» 

IWU-INFO 


■4 

IE «IWU to IWU= edit entry confirm, session id, start index » 

IWU-INFO 


«IWU to IWU= data packet last, session id, content part= content part for i tn entry 



User updates the settings for i line in line settings list 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier » 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part= i entry updated » 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, position index 
total number of available entries » 
IWU-INFO 



IE «IWU to IWU= end session, session identifier» 
IWU-INFO 



IE «IWU to IWU= end session confirm, session identifier » 

FACILITY 



«EVENTS NOTIFICATIONS, <List change indication, Line settings, N> > 

« CALL-INFORMATION, Lineld » 

CC-RELEASE 



CC-RELEASE-COM 



FP notifies 
all PP 

attached to 
the line 



Figure C.35: Changing the settings of a line (use case 2) 
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C.8.3 Changing the name of a line 

Use case: The user edit directly the line name of the line number '3'. 



PP FP 





CC-SETUP 




«Basic Service=< Call Class = LiA Service call setuD > » 
CC-CALL-PROC 

4 


IWU-INFO 


► 

IE «IWU to IWU= start session, lines settings list, Number of sorting fields =0» 

IWU-INFO 


IE «IWU to IWU= start session confirm, session identifier, Total number=N 

IWU^NFO 


► 

IE «IWU to IWU= read entries, session id, start index= index line 3, 
direction=forward, counter=1 , list of field identifiers= Line Id id, Line name id » 

IWU-INFO 


■* 

IE «IWU to IWU= read entries confirm, session id, start index, counter=1 » 

IWU-INFO 


4 

IE «IWU to IWU= data packet last, session id, content part= (entry identifier, 
line Id, Line name) for 'line 3' » 

IWU-INFO 


► 

IE «IWU to IWU= edit entry, session id, entry identifier, list of field identifiers= 
Line Id id, Line name id » 
IWU-INFO 


< 

IE «IWU to IWU= edit entry confirm, session id, start index » 

IWU-INFO 


< 

IE «IWU to IWU= data packet last, session id, content part = (entry identifier, 
line Id, Line name) for 'line 3' » 


User updates the 'Line name' field for 'line 3' entry in line settings list 






IWU-INFO 

► 


3d» 


IE «IWU to IWU= save entry, session id, entry identifier» 
IWU-INFO 

► 


E «IWU to IWU= data packet last, session id, content part = 'line 3' content updal 

IWU-INFO 


* IE «IWU to IWU= save entry confirm, session id, entry identifier, position 
index, total number of available entries » 

IWU-INFO p 


IE «IWU to IWU= end session, session identifier» 
IWU-INFO 

* 


IE «IWU to IWU= end session confirm, session identifier » 

FACILITY 


FP notifies all PP 
attached to the 
line 


«EVENTS NOTIFICATIONS, <List change indication, Line settings, 
N> > « CALL-INFORMATION, Lineld » 

CC-RELEASE 




► 

CC-RELEASE-COM 

< 





Figure C.36: Changing the name of a line 
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C.8.4 Changing the name of a line (PIN protected field) 

Use case: the use case is the same as the previous one except that the 'linename' field is PIN code protected. 
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PP 



FP 



Line settings start session (on encrypted link) 



Read Lin ! '3' settings: 



IWU-INFO 



IE «IWU to IWU= read entries, session id, start index= index line 3, 
direction=forward, counter=1 , list of field identifiers= Line Id id, Line name id » 



IE «IWU to IWU= read entries confirm, session id, start index, counter=1» 

IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part= (entry identifier, 
line Id, Line name) for 'line 3' » 



PIN code 



checking: might be done at any time during the LiA service call (here or befor s) 



Start a DECT system settings list session 



Edit and save the current PIN code 



FP checks if PIN code entered by the user matches current system PIN 



Close the DECT system settings list session (optional) 



If entered] PIN code matches current system PIN 

IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, list o 
Line Id id, Line name id » 

IWU-INFO 



fiers= 



IE «IWU to IWU= edit entry confirm, session id, start index » 

IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part = (entry identifier, 
line Id, Line name) for 'line 3' » 



user updates the 'Line name' field for 'line 3' entry in line settings list 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier» 
IWU-INFO 



dWU to IWU= data packet last, session id, content part = 'line 3' content update<|» 
IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, position 
index, total number of available entries » 



Line settings end session 



FACILITY 



«EVENTS NOTIFICATIONS, <List change indication, Line settings, N> > 

« CALL-INFORMATION, Lineld » 



Figure C.37: Changing the name of a line (PIN protected field) 



FP notifies all PP 
attached to the 
line 
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C.9 Use cases for 'Off-hook CLIP enabled DCIBS' lines 

This annex studies complex use cases for the 'Handling of lines where second calls are signalled in-band' feature (see 
clause 7.4.3.10). 

C.9.1 Remote party hang-up 'double call with in-band signalling' 
line 

This clause illustrates some of the issues possibly occurring on Off-hook CLIP enabled DCIBS lines when a remote 
party hangs up, but the FP is not aware of this event. See clause 7.4.3.10.3.1, subclause 'Remote party hang up for a 
second call'. 

C.9.1 .1 Call waiting after 'remote party hang-up' 

In this use case, the FP becomes aware of a remote party hang-up when a new call waiting is indicated by the network. 
As a result, the FP releases one of the two existing calls by issuing a 'CS idle' call status with the corresponding call id 
(late release). Two sub cases are covered: 

• late release (see note 1) of a former call waiting when a new call waiting occurs; 
NOTE 1: The 'late release' is defined in clause 3.1. 

NOTE 2: In the above sub case, the late release is not needed if the former call waiting has already been released 
following a timeout (never accepted waiting call). 

• late release of the call on-hold when a call waiting occurs. 

In both cases, the FP chooses to release the non-active call (former call waiting or call on-hold). In some case however, 
the FP might release the wrong call (i.e. if the remote party of the active call hanged up). In that case, the user may be 
faced with issue 2 described in the 'remote party hang-up for a second call' subsection of clause 7.4.10.3.1. 
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PP 



FP 



K 1 



If required by the 'Tones 



context with call id 2 
created on PP side 



Call context for call id 2 
still in alerting state 



External call 1 (with call id 1) currently in use by PP 



Call waiting indication 

CC-INFO 



« SIGNAL value = 'call waiting tone' = '07'H » 
« CALLING PARTY NUMBER, < Calling Party Address = 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', valu i 

< id type='Line identifier', subtype='line type information', 

< id type = 'Call identifier', value = 'waiting call id' = '02'H 

< id type/subtype = 'Call status', value = 'CS call setup' 



Late release of former call waiting (call id 2) 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS idle' > 



New call waiting indication 

CC-INFO 



External 
call waiting from 
'calling number' 



ailing number' > » 



'waiting call line id' > 
/alue = "ly'B> 



1- CW remote party hang- 
up (not detected by the FP) 

2- Off-hook CLIP (indicating 
new call waiting) 



3- FP guesses call 2 
remote hang up and 
performs a late 
release of that call 

(see note 1 & 2) 



« SIGNAL value = 'call waiting tone' = '07'H » 

« CALLING PARTY NUMBER, < Calling Party Address = 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value 

< id type='Line identifier', subtype='line type information', 

< id type/subtype = 'Call identifier', value = '03'H > 

< id type/subtype = 'Call status', value = 'CS call setup' : 



:alling number' > » 

'waiting call line id' > 
value = '1y'B> 



Figure C.38: Late release of former call waiting following new call waiting indication 
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PP 



FP 



Two existing call 
contexts on PP side 



If required by the 'Tones 



External call 1 (with call id 1) currently in use by PP 
External call 2 (with call id 2) on-hold 



Late release of call on-hold (call id 2) 

CC-INFO 



« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '02'H > 

< id type/subtype = 'Call status', value = 'CS idle' > 



Call waiting indication 

CC-INFO 



1- Remote party hang-up 

(not detected by the FP) 

2- Off-hook CLIP (indicating 
new call waiting) 



3- FP guesses call 2 
remote hang up and 
performs a late 
release of that call 

(see note 1 ) 



« SIGNAL value = 'call waiting tone' = '07'H » 
« CALLING PARTY NUMBER, < Calling Party Address = 'cilling number' > » 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', value 

< id type='Line identifier', subtype='line type information', vfelue 

< id type = 'Call identifier', value = 'waiting call id' = '03'H 

< id type/subtype = 'Call status', value = 'CS call setup' 



waiting call line id' > 
1y'B> 



Figure C.39: Late release of call on-hold following call waiting indication 



C.9.1 .2 Outgoing parallel call after 'remote party hang-up' 

In this use case, the FP becomes aware of a remote party hang-up when the user initiates an outgoing parallel call. As a 
result, the FP releases one of the two existing calls by issuing a 'CS idle' call status with the corresponding call id (late 
release). Two sub cases are covered: 

• late release (see note 1) of the call waiting when an outgoing parallel call occurs; 
NOTE 1: The 'late release' is defined in clause 3.1. 

NOTE 2: In the above sub case, the late release is not needed if the call waiting has already been released following 
a timeout (never accepted waiting call). 

• late release of the call on-hold when an outgoing parallel call occurs. 

In both cases, the FP chooses to release the non-active call (call waiting or call on-hold). In some case however, the FP 
might release the wrong call (i.e. if the remote party of the active call hanged up). In that case, the user may be faced 
with issue 2 described in the 'remote party hang-up for a second call' subsection of clause 7.4.10.3.1. 
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< id type/subtype = 'Call identifier', value = '01 'H > 
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» 

CC-INFO Late release of call waiting (call id 2) 
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« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', value = '03'H > 
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Figure C.40: Late release of call waiting following outgoing parallel call initiation 
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Figure C.41 : Late release of call on-hold after remote party hang-up 
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Annex D (informative): 

Guidelines for implementation of DTMF 

D.1 Uplink DTMF transmission from FP to network 



Upon reception of the keypad information element from the PP. the FP has two options according to the network 
capabilities: 

• Digits are transmitted out of band using dedicated signalling. 

• Digits are transmitted in band by inserting the corresponding audio encoded patterns in the audio bit stream in 
the active codec format. 

When connected to PSTN networks, the in-band generation method is used by the FP. 

If the FP is able to place calls on several lines from different networks that use different DTMF methods, the FP might 
have to adapt the uplink DTMF transmission on a line by line basis. This could be the case with the multiple lines 
feature. For example, one PSTN line uses the in-band method, and another VoIP line uses the out of band method. 



The current clause is valid for: 

• in-band DTMF generation from FP to PP; or 

• in-band DTMF generation from FP to network when in-band method is supported on network side. 
In-band DTMF is generated in the active codec format. 

The DTMF should respect ITU-T standards Q.23 [i.8] which defines pair of frequencies to be used and 
Recommendation ITU-T Q.24 [i.9] which defines levels and durations. 

A recommended implementation for level and duration for the DTMF is the following: 

• Tone generation level: nominal - 10 dBmO per frequency 

• Tone generation time min: 80 ms 

• Inter DTMF generation time min: 80 ms 



D.2 



DTMF format 
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Annex E (informative): 

Tones format in ITU-T recommendations 

The generated tones should be compliant with Recommendations ITU-T E.180 [i.10] and [i.l 1] and E.182 [i. 12]. 



Table E.1 : Tones in ITU-T recommendations 



DECT Tones 


ITU-T Tones 


Ring-back tone 


Ringing tone 


Busy tone 


Busy tone 


Network congestion tone 


Congestion tone 


Call waiting tone 


Call waiting tone 


Intercept tone 


Intercept tone (note) 


Negative acknowledgment tone 


Negative indication tone (note) 


Dialling tone 


Dialling tone 


Off-hook warning tone 


Special information tone 



NOTE: These tones are not defined for all countries. Implementers should select one tone format among those 
available in Recommendation ITU-T E.182 [i.12]. 
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Annex F (informative): 

Services and features defined in other specifications 

F.1 Services and features defined in TS 102 527-1 (New 
Generation DECT; part 1) 

The following informative annex shows the features and services defined in TS 102 527-1 [21] (New Generation 
DECT; part 1), many of them are reused in the present document. This list is informative, and shows the status in TS 
102 527-1 [21] (Vl.2.1). Where there are changes or divergences the original definitions at TS 102 527-1 [21] apply. 

F.1 .1 New Generation DECT; part 1 , Speech Services (clause 5.1 
of TS 102 527-1) 

Narrow band ADPCM G.726 voice service [NG1.1]: Recommendation ITU-T G.726 [15] narrowband codec 
[NG1.SC.1] over 32 kbit/s unprotected transmission channel. 

Narrow band PCM G.711 voice service [NG1.2]: Recommendation ITU-T G.71 1 [16] narrow band codec 
[NG1.SC.2] over 64 kbit/s protected or unprotected transmission channels. 

Wideband 7 kHz G.722 voice service [NG1.3]: Recommendation ITU-T G.722 [17] wideband codec [NG1.SC.3] 
over 64 kbit/s protected or unprotected transmission channels. 

Wideband 7 kHz low rate G.729.1 voice service [NG1.4]: Recommendation ITU-T G.729.1 [18] wideband codec 
[NG1.SC.4] over 32 kbit/s unprotected transmission channels. 

Super wideband 14 kHz MPEG-4 ER AAC-LD voice service [NG1.5]: MPEG-4 ER AAC-LD super wideband 
codec [NG1.SC.5] over 64 kbit/s protected or unprotected transmission channels. 

Wideband 11 kHz low rate MPEG-4 ER AAC-LD voice service [NG1.6]: MPEG-4 ER AAC-LD super wideband 
codec [NG1.SC.6] over 32 kbit/s unprotected transmission channels. 

F.1 .2 New Generation DECT; part 1 , Network (NWK) features 
(clause 5.2 of TS 102 527-1) 

Codec Negotiation [NG1.N.1): capability to negotiate the speech codec to be used in a communication, based on the 
supported capabilities in both peers and the previsions included in the present document. This feature may require slot 
type change. 

Codec Switching [NG1.N.2): capability to switch between different speech codecs during a call. This feature may 
require slot type change. 

F.1 .3 New Generation DECT; part 1 , Data Link Control (DLC) 
services (clause 5.3 of TS 102 527-1) 

LUl Transparent Unprotected service (TRUP) Class 0/minimum_delay [NG1.D.1]: transparent unprotected 
service introducing minimum delay, transmission Class 0/min_delay as defined by EN 300 175-4 [4], clause 1 1.2. 

LUl Transparent Unprotected service (TRUP) Class [NG1.D.2]: transparent unprotected service introducing 
minimum delay, transmission Class as defined by EN 300 175-4 [4], clause 1 1.2. 

LU7 64 kbit/s protected bearer service [NG1.D.3]: protected service providing reliable 64 kbit/s transmission over 
packet type P80 incorporating FEC and ARQ protection mechanisms. Defined by EN 300 175-4 [4], clause 1 1.9. 
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LU12 UNProtected Framed service (UNF) Class [NG1.D4]: unprotected service introducing normal delay, 
transmission Class as defined by EN 300 175-4 [4], clause 11.14. 

FU1 DLC frame [NG1.D.5]: bidirectional frame used in LU1 service. Defined in EN 300 175-4 [4], clause 12.2. 
Frame length depends on slot type and is defined in table 12.2.1.1 of EN 300 175-4 [4], clause 12.2.1. 

FU7 DLC frame [NG1.D.6]: bidirectional frame used in LU7 service. Defined in EN 300 175-4 [4], clause 1 1.9. 

FU12 DLC frame with adaptation for codec G.729.1 [NG1.D.7]: bidirectional frame used in LU12 service, as 
defined in EN 300 175-4 [4], clause 12.12, frame size specified for full slot, 2-level modulation and with the adaptation 
for codec G.729.1 defined in EN 300 175-4 [4], clause E.l. 

F.1 .4 New Generation DECT; part 1 , Medium Access Control 
(MAC) services (clause 5.4 of TS 102 527-1) 

I N _minimum delay symmetric MAC service type [NG1.M.1]: I N _minimum delay symmetric connection as defined 
in EN 300 175-3 [3], clause 5.6.2.1. 

I N _normal delay symmetric MAC service type [NG1.M.2]: I N _normal delay symmetric connection as defined in 
EN 300 175-3 [3], clause 5.6.2.1. 

IpQ_error_detection symmetric MAC service type [NG1.M.3]: I PQ _ error_detection symmetric connection as defined 
in EN 300 175-3 [3], clause 5.6.2.1. (type 3: I P _ error_detection with single-subfield protected B-field as defined in 
EN 300 175-3 [3], clause 6.2.1.3.4). 

Advanced Connections [NG1.M.4]: MAC Connection Oriented service providing connection between FT and PT. 
Advanced connections are able to support multiple bearers, bearers different of the full slot, and any MAC service. The 
service includes the means for setting up and releasing the required bearer(s). 

F.1 .5 New Generation DECT; part 1 , Physical Layer (PHL) 
services (clause 5.5 of TS 102 527-1) 

2 level GFSK modulation [NG1.P.1]: 2 level Gaussian frequency Shift Key (GFSK) modulation as defined by 
EN 300 175-2 [2], clause 5. 

Physical Packet P32 [NG1.P.2]: physical packet P32 (full slot) as defined by EN 300 175-2 [2], clause 4.4.2. 

Physical Packet P64 [NG1.P.3]: variable capacity Physical packet POOj as defined by EN 300 175-2 [2], clause 4.4.3, 
withj = 640. 

Physical Packet P67 [NG1.P.4]: variable capacity Physical packet POOj as defined by EN 300 175-2 [2], clause 4.4.3, 
with j = 672. 

Physical Packet P80 [NG1.P.5]: physical packet P80 (double slot) as defined by EN 300 175-2 [2], clause 4.4.4. 

F. 1 .6 New Generation DECT; part 1 , Speech coding and audio 

features (clause 5.6 of TS 102 527-1) 

G. 726 32 kbit/s ADPCM [NG1.SC.1]: Recommendation ITU-T G.726 [15] narrow band codec as defined by 

EN 300 175-8 [8], clause 5.1. Recommendation ITU-T G.726 [15] codec is mandatory for New Generation DECT in 
order to ensure interoperability with existing DECT systems. 

G.711 64 kbit/s log-PCM [NG1.SC.2]: Recommendation ITU-T G.71 1 narrow band codec [16] as defined by 

EN 300 175-8 [8], clause 5.2. Recommendation ITU-T G.711 [16] codec is optional for New Generation DECT in order 

to improve the quality of narrow band communications, and fax/modem transmissions. 

Recommendation ITU-T G.711 [16] provides a slightly higher intrinsic voice quality and no transcoding for PSTN 
calls. Both, A-Law and u-Law are supported. 
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G.722 64 kbit/s wideband [NG1.SC.3]: Recommendation ITU-T G.722 wideband SB-ADPCM 7 kHz codec [17] as 
defined by EN 300 175-8 [8], clause 5.3. Recommendation ITU-T G.722 [17] is chosen as mandatory wideband codec 
for New Generation DECT in order to greatly increase the voice quality by extending the bandwidth from narrow band 
to wideband. Recommendation ITU-T G.722 [17] provides a high wideband quality at a bit rate of 64 kbit/s with low 
complexity and very low delay. 

G.729.1 32 kbit/s wideband [NG1.SC.4]: Recommendation ITU-T G.729.1 wideband codec [18] as defined by 
EN 300 175-8 [8], clause 5.4. Recommendation ITU-T G.729.1 [18] codec is optional for New Generation DECT in 
order to provide even higher wideband quality and better robustness to packets/frames losses than 
Recommendation ITU-T G.722 [17] at half the bit rate of Recommendation ITU-T G.722 [17]. This allows a better 
transport efficiency on the network side and over the DECT air interface (one full slot). In addition, it is seamless 
interoperable with largely deployed Recommendation ITU-T G.729 [i.7] based VoIP networks and terminals. 
Recommendation ITU-T G.729.1 [18] encodes signals in frames of 20 ms. It is a scalable codec operating at bitrates of 
8 kbit/s and from 12 kbit/s to 32 kbit/s per steps of 2 kbit/s, in narrow band or in wideband from 14 kbit/s. 
Recommendation ITU-T G.729.1 [18] already incorporates a high efficiency packet loss concealment mechanism. 

MPEG-4 ER AAC-LD 64 kbit/s super wideband [NG1.SC.5]: MPEG-4 ER AAC-LD codec as defined by 
ISO/IEC 14496-3:2009: [20] and by EN 300 175-8 [8] clause 5.5.1. MPEG-4 ER AAC-LD is optional for New 
Generation DECT in order to provide higher quality than G.722 by further extending the bandwidth to superwideband 
(50 Hz to 14 kHz) (and even further, up to full audio bandwidth (20 Hz to 20 kHz)). MPEG-4 ER AAC-LD is designed 
for high quality communication applications including all kind of audio signals e.g. speech and music and provides a 
high quality for music streaming or other multimedia applications mixing speech and music. It provides an audio 
bandwidth of 14 kHz or more at a bitrate of 64 kbit/s. MPEG 4 ER AAC-LD (Error resilient, Low Delay AAC profile) 
is standardized as an audio profile of MPEG-4 (ISO/IEC 14496-3 [20]). The frame size is 10 ms and the algorithmic 
delay 20 ms. 

MPEG-4 ER AAC-LD 32 kbit/s wideband [NG1.SC.6]: As [NG1.SC5], but using the 32 kbit/s mode, as defined by 
EN 300 175-8 [8], clause 5.5.2. It provides a bandwidth of 1 1,5 kHz or more. The frame size is 20 ms and the 
algorithmic delay 40 ms. 

PLC (Packet Loss Concealment) G.722 Appendix III & IV [NG1.SC.7]: To better cope with transmission errors, a 
Packet Loss Concealment algorithm (PLC) as defined by EN 300 175-8 [8], clause 5.3.2 may be optionally 
implemented for Recommendation ITU-T G.722 [17]. Appendices III and IV describe packet loss concealment 
solutions extending the Recommendation ITU-T G.722 [17] decoder. These PLC algorithms maybe optionally 
implemented to improve voice quality in degraded transmission conditions where packets/frames may be lost (in IP 
network or on DECT air interface). 

NOTE 1 : Both appendices meet the same quality requirements but address two different quality/complexity 
tradeoffs: 

1) Appendix III aims at maximizing the robustness at a price of additional complexity. 

2) Appendix IV proposes an optimized complexity/quality trade off with almost no additional 
complexity compared with Recommendation ITU-T G.722 [17] normal decoding (0,07 WMOPS). 

Since Recommendation ITU-T G.722 [17] does not incorporate any mechanism to cope with lost frames/packets, the 
use of a PLC algorithm is strongly recommended to avoid annoying effects in the case of packet/frame losses. 

NOTE 2: Recommendation ITU-T G.729.1 [18] already incorporates a packet loss concealment mechanism. 

Detection of Modem/fax tone [NG1.SC.8]: Detection of the 1 100 Hz, 1 300 Hz and 2 100 Hz standard tones 
indicating a fax/modem transmission and answering, as defined by EN 300 175-8 [8] clause 5.2.2. The main utility of 
this function is the switching of codecs to transparent PCM (Recommendation ITU-T G.71 1 [16]) in order to facilitate 
modem/fax transmission. The tone detection can also be used to de-activate echo suppression if present. 

Codec selection and switching [NG1.SC.9]: To handle several codecs (at least Recommendation ITU-T G.726 [15] 
and Recommendation ITU-T G.722 [17]), New Generation DECT will support a codec selection and switching 
mechanism. This may consequently allow the use of other codecs that could be specified in next releases as additional 
optional codecs according to future application or interoperability needs. 

PP Audio type la ("classic GAP" handset) [NG1.SC.10]: Audio specification for a general purpose 3,1 kHz 
telephony handset as defined by EN 300 175-8 [8], clause 7.2.3. 
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PP audio type lb ("improved GAP" handset) [NG1.SC.11]: Audio specification for a general purpose 3,1 kHz 
telephony handset with improved TCLw, as defined by EN 300 175-8 [8], clause 7.2.4. It is compatible with VoIP and 
long delay networks. 

PP audio type lc (HATS tested, 3,1 kHz handset) [NG1.SC.12]: Audio specification for a general purpose 3,1 kHz 
telephony handset based on the new HATS methodology, as defined by EN 300 175-8 [8], clause 7.2.5. It includes 
strong echo suppression (TCLw) requirements and is compatible with VoIP and long delay networks. 

PP audio type Id (HATS tested, 3,1 kHz "improved" handset) [NG1.SC.13]: Audio specification for a general 
purpose 3,1 kHz telephony handset based on the new HATS methodology with improved quality, as defined by 
EN 300 175-8 [8], clause 7.2.6. It includes strong echo suppression (TCLw) requirements and is compatible with VoIP 
and long delay networks. This type has a more demanding acoustic specification, providing superior subjective quality. 
In practice, this means better electro acoustic components (speaker, microphone), electronics and signal processing. 

PP Audio type 2a (Recommendation ITU-T P.311 [i.6] 7 kHz handset) [NG1.SC.14]: Audio specification for a 
wideband, 7 kHz service, handset based on the Recommendation ITU-T P.31 1 [i.6], as defined by EN 300 175-8 [8], 
clause 7.2.9. 

PP Audio type 2b (HATS 7 kHz handset) [NG1.SC.15]: Handset for 7 kHz service (wideband), based on HATS 
methodology, as defined by EN 300 175-8 [8], clause 7.2.10. It includes strong echo suppression (TCLw) requirements 
and is compatible with VoIP and long delay networks. 

PP Audio type 2c (HATS 7 kHz "improved" handset) [NG1.SC.16]: Handset for 7 kHz service (wideband), based 
on HATS methodology, with improved quality, as defined by EN 300 175-8 [8], clause 7.2.1 1. It includes strong echo 
suppression (TCLw) requirements and is compatible with VoIP and long delay networks. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro acoustic 
components (speaker, microphone), electronics and signal processing. 

PP audio type 3a (HATS tested, 3,1 kHz handsfree) [NG1.SC.17]: Audio specification for a Narrowband (3,1 kHz) 
handsfree device as defined by EN 300 175-8 [8], clause 7.2.7. This type applies to handsfree devices operating with an 
open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, lc or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz to 3,4 kHz) frequency range, and it is defined based on HATS methodology. 

PP audio type 3b (HATS tested, 3,1 kHz "improved" handsfree) [NG1.SC.18]: Audio specification for a 
Narrowband (3,1 kHz) handsfree device, improved quality version, as defined by EN 300 175-8 [8], clause 7.2.8. This 
type applies to handsfree devices operating with an open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, lc or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz to 3,4 kHz) frequency range, and it is defined based on HATS methodology. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro acoustic 
components (speaker, microphone), electronics and signal processing. 

PP Audio type 4a (HATS 7 kHz handsfree) [NG1.SC.19]: Wideband (7 kHz) handsfree device, as defined by 
EN 300 175-8 [8], clause 7.2.12. This type applies to handsfree devices operating with an open loudspeaker and 
microphone. The profile applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard wideband handset implementing profiles 2a, 2b or 2c, but with the option to operate in handsfree 
mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 
It provides (150 Hz to 7 kHz) frequency range, and it is defined based on HATS methodology. 
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PP Audio type 4b (HATS 7 kHz "improved" handsfree) [NG1.SC.20]: Wideband (7 kHz) handsfree device, 
improved quality version, as defined by EN 300 175-8 [8], clause 7.2.13. This type applies to handsfree devices 
operating with an open loudspeaker and microphone. The profile applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard wideband handset implementing profiles 2a, 2b or 2c, but with the option to operate in handsfree 
mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (150 Hz to 7 kHz) frequency range, and it is defined based on HATS methodology. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro acoustic 
components (speaker, microphone), electronics and signal processing. 

PP Audio type 5a (Super wideband 14 kHz) [NG1.SC.21]: Handset for 14 kHz service (super wideband), as defined 
by EN 300 175-8 [8], clause 7.2.14. 

PP Audio type 5b (Super wideband 14 kHz, handsfree) [NG1.SC.22]: Handsfree device for 14 kHz service (super 
wideband), as defined by EN 300 175-8 [8], clause 7.2.15. 

FP audio type lb ("new ISDN" 3,1 kHz) [NG1.SC.23]: Audio specification for a DECT FP supporting narrowband 
service and providing a digital 64 kbit/s G.711 interface, typically (but not necessarily) an ISDN connection, new 
specification, as defined by EN 300 175-8 [8], clause 7.3.3. 

NOTE 3: FP Audio type la ("classic ISDN", 3,1 kHz FP, see EN 300 175-8 [8]) is not to be used in New 

Generation DECT equipment. Instead of it, FP type lb should be used in NG-DECT FPs with ISDN or 
digital circuit-switch interfaces. 

PP echo canceller for FP, narrowband (3,1 kHz) service [NG1.SC.24]: Auxiliary feature for FPs consisting on echo 
canceller for handling the echo generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.2. Only 
narrowband echo cancellation capability is required for this feature. 

PP echo suppressor for FP, narrowband (3,1 kHz) service [NG1.SC.25]: Auxiliary feature for FPs consisting on 
echo suppressor for handling the echo generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.3. Only 
narrowband capability is required for this feature. 

FP audio type 2 (analog PSTN 3,1 kHz) [NG1.SC.26]: Audio specification for a DECT FP supporting narrowband 
service and providing an analog 2-wire PSTN interface. As defined by EN 300 175-8 [8], clause 7.3.4. 

FP audio type 3 (VoIP 3,1 kHz) [NG1.SC.27]: Audio specification for a DECT FP supporting narrowband service and 
providing a VoIP interface, with codecs G.711 (typically) or G.726 on top of it. As defined by EN 300 175-8 [8], 
clause 7.3.5. 

FP Audio type 4 (ISDN, wideband) [NG1.SC.28]: Audio specification for a DECT FP supporting wideband service 
and providing a digital 64 kbit/s interface, typically (but not necessarily) an ISDN connection, with a wideband codec 
such as G.722, MPEG, etc. As defined by EN 300 175-8 [8], clause 7.3.6. 

FP Audio type 5 (VoIP wideband) [NG1.SC.29]: Audio specification for a DECT FP supporting wideband service 
and providing a VoIP interface, with a wideband codec on top such as G.722, MPEG, etc. As defined by 
EN 300 175-8 [8], clause 7.3.8. 

PP echo canceller for FP, wideband (7 kHz) service [NG1.SC.30]: Auxiliary feature for FPs consisting on echo 
canceller for handling the echo generated by PPs type 2a. As defined by EN 300 175-8 [8], clause 7.4.2. Only wideband 
echo cancellation capability is required for this feature. 

PP echo suppressor for FP, wideband (7 kHz) service [NG1.SC.31]: Auxiliary feature for FPs consisting on echo 
suppressor for handling the echo generated by PPs type 2a. As defined by EN 300 175-8 [8], clause 7.4.3. Only 
wideband echo cancelation capability is required for this feature. 

FP audio type 6a (internal call) [NG1.SC.32]: This type of audio specification applies to the case of internal call 
inside a DECT FP or a DECT system without any external interface. This type applies to any service. As defined by 
EN 300 175-8 [8], clause 7.3.8. 
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FP audio type 6b (internal conference) [NG1.SC.33]: This type of audio specification applies to the case of 3-party 
or multi-party conference inside a DECT FP or a DECT system with or without an external interface. Applies to any 
service. As defined by EN 300 175-8 [8], clause 7.3.9. 

Adaptive volume control for FP [NG1.SC.34]: Accessory feature for FPs consisting on an adaptive volume control 
depending on the level of environmental noise at the PP. The gain variation should be symmetrical. As described in 
EN 300 175-8 [8], clause 7.6 and informative annex D. 



F.2 Services and features defined in EN 300 444 (GAP) 

The following informative annex shows the features and services defined in EN 300 444 [12] (GAP), many of them are 
reused in the present document. This list is informative, and shows the status in EN 300 444 [12]. Where there are 
changes or divergences the original definitions at EN 300 444 [12] (GAP) apply. 

F.2.1 GAP Network (NWK) features (clause 4.1 of EN 300 444) 

outgoing call [N.l]: call initiated at a DECT PP. 

off-hook [N.2]: ability to indicate the action of going off-hook, e.g. to start call setup or accept a call. 

on-hook (FULL Release) [N.3]: ability to indicate the action of going on-hook (e.g. to terminate a call) and fully 
release the radio resource. 

dialled digits (basic) [N.4]: capability to dial digits to 9, *, #. 

register recall [N.5]: ability of the PP to request the invocation of the supplementary service "register recall" over the 
DECT interface and the ability of the FP to transmit the request to the local network. Register recall means to seize a 
register (with dial tone) to permit input of further digits or other action. 

go to DTMF signalling (defined tone length) [N.6]: go to DTMF signalling with defined tone length, 
pause (dialling pause) [N.7]: ability to generate or indicate a dialling pause, e.g. to await further dial tone, 
incoming call [N.8]: call received at a DECT PP. 

authentication of PP [N.9]: process by which the identity of a DECT PP is checked by the FP. 

authentication of user [N.10]: process by which the identity of a user of a DECT PP is checked by the FP. The User 
Personal Identification (UPI), a personal identification of to 8 digits, manually entered by the user, is used for user 
authentication. 

location registration [N.ll]: facility whereby a PP can be registered with a FP or a cluster of FPs such that incoming 
calls, radio pages or messages may be routed to it. 

on-air key allocation [N.12]: capability to transform Authentication Code (AC) into User Authentication Key (UAK) 
using the key allocation procedure. 

identification of PP [N.13]: ability for the FP to request and PP to provide specific identification parameters. 

service class indication/assignment [N.14]: assignment by the FP to PP of the service class and indication to the FP by 
the PP of the contents of its service class. 

alerting [N.15]: activates or deactivates alerting at the PP using any appropriate indication. 

ZAP [N.16]: ability first to assign and then to re-program the account data held in the PP so that access rights may be 
suspended subject to the conditions set by the service provider being met, coupled with the ability to re-program the 
account data again to reinstate access rights once these conditions have been met. One ZAP field should be provided per 
account field. The PP has the right to authenticate the FP prior to the execution of ZAP suspend. 

encryption activation FT initiated [N.17]: activation of the encryption process requested by FT. 

subscription registration procedure on-air [N.18]: standardized procedure for loading subscription registration data 
into a PP in real time over the air-interface. 
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link control [N.19]: ability to request, accept, maintain and release a data link for the purposes of a NWK layer 
procedure. 

terminate access rights FT initiated [N.20]: ability of the FP to delete a subscription in the PP. 

partial release [N.21]: ability to release an established or in progress Call Control (CC) call whilst retaining the radio 
resource for the purpose of accessing further services. 

go to DTMF (infinite tone length) [N.22]: go to DTMF signalling, indicating infinite DTMF tone duration, 
go to pulse [N.23]: go to pulse (decadic) signalling. 

signalling of display characters [N.24]: transmission to the PP of characters to be displayed on the user's PP display 
(if provided). 

display control characters [N.25]: characters sent to the PP to control the user's display in the PP (if provided). Such 
characters include cursor control, clear screen, home, flash, inverse video, etc. 

authentication of FT [N.26]: process by which the identity of a FP is checked by the PP. 

encryption activation PT initiated [N.27]: activation of the encryption process suggested by PT. The real time start of 
ciphering is done in the MAC layer and is always initiated by the PT. 

encryption deactivation FT initiated [N.28]: deactivation of the encryption process requested by FT. The real time 
stop of ciphering is done in the MAC layer and is always initiated by the PT. 

encryption deactivation PT initiated [N.29]: deactivation of the encryption process suggested by PT. The real time 
stop of ciphering is done in the MAC layer and is always initiated by the PT. 

Calling Line Identification Presentation (CLIP) [N.30]: ability to provide the calling party number to the called party 
before accepting the call. 

internal call [N.31]: call between 2 users that does not make use of the local network resources. This is typically useful 
in residential environments. 

service call [N.32]: call initiated by a DECT PT for entering of FT related service and adjustment procedures in a 
transparent way. After having sent the service call indication, the PT behaves according to the rules of a normal call. 

Enhanced U- plane connection [N.33]: ability of the FT to initiate connection of the U- plane during call 
establishment or release e.g. to facilitate the provision of in band tones or announcements. 

Calling Name Identification Presentation (CNIP) [N.34]: ability to provide the calling party name to the called party 
before accepting the call. 

Enhanced Security [N.35]: mechanism to enhance DECT security by introduction of early encryption and the 
possibility of re-keying during an ongoing call. 

AES/DSAA2 authentication [N.36]: authentication using the DECT Authentication Algorithm #2 (DSAA2), based on 
AES, and including type 2 (see EN 300 175-7 [7]) air i/f procedures. 

F. 2.2 GAP Speech coding and audio features (clause 4.2 of 

EN 300 444) 

For the purposes of the present document the following definitions apply: 

G. 726 32 kbit/s ADPCM [SCI]: Recommendation ITU-T G.726 [15] narrow band codec as defined by 
EN 300 175-8 [8] clause 5.1. 

PP audio type la ("classic GAP" handset) [SC.2]: audio specification for a general purpose 3,1 kHz telephony 
handset as defined by EN 300 175-8 [8], clause 7.2.3. 

PP audio type lb ("improved GAP" handset) [SC.3]: audio specification for a general purpose 3,1 kHz telephony 
handset with improved TCLw, as defined by EN 300 175-8 [8], clause 7.2.4. It is compatible with VoIP and long delay 
networks. 
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PP audio type lc (HATS tested, 3,1 kHz handset) [SC.4]: audio specification for a general purpose 3,1 kHz 
telephony handset based on the new HATS methodology, as defined by EN 300 175-8 [8], clause 7.2.5. It includes 
strong echo suppression (TCLw) requirements and is compatible with VoIP and long delay networks. 

PP audio type Id (HATS tested, 3,1 kHz "improved" handset) [SC.5]: audio specification for a general purpose 
3,1 kHz telephony handset based on the new HATS methodology with improved quality, as defined by 
EN 300 175-8 [8], clause 7.2.6. It includes strong echo suppression (TCLw) requirements and is compatible with VoIP 
and long delay networks. This type has a more demanding acoustic specification, providing superior subjective quality. 
In practice, this means better electro-acoustic components (speaker, microphone), electronics and signal processing. 

PP audio type 3a (HATS tested, 3,1 kHz handsfree) [SC.6]: audio specification for a Narrowband (3,1 kHz) 
handsfree device as defined by EN 300 175-8 [8], clause 7.2.7. This type applies to handsfree devices operating with an 
open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, lc or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz to 3,4 kHz) frequency range, and it is defined based on HATS methodology. 

PP audio type 3b (HATS tested, 3,1 kHz "improved" handsfree) [SC.7]: audio specification for a Narrowband 
(3,1 kHz) handsfree device, improved quality version, as defined by EN 300 175-8 [8], clause 7.2.8. This type applies to 
handsfree devices operating with an open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, lc or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz to 3,4 kHz) frequency range, and it is defined based on HATS methodology. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro-acoustic 
components (speaker, microphone), electronics and signal processing. 

FP audio type la ("classic ISDN" 3,1 kHz) [SC.8]: audio specification for a DECT FP supporting narrowband service 
and providing a digital 64 kbit/s G.71 1 interface, typically (but not necessarily) an ISDN connection, classic 
specification, as defined by EN 300 175-8 [8], clause 7.3.2. It is recommended to use FP type lb instead of type la. 

FP audio type lb ("new ISDN" 3,1 kHz) [SC.9]: audio specification for a DECT FP supporting narrowband service 
and providing a digital 64 kbit/s G.71 1 interface, typically (but not necessarily) an ISDN connection, new specification, 
as defined by EN 300 175-8 [8], clause 7.3.3. It is recommended to use FP type lb instead of type la. 

PP echo canceller for FP [SC. 10]: auxiliary feature for FPs consisting on echo canceller for handling the echo 
generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.2. Only narrowband echo cancellation capability 
is required. 

PP echo suppressor for FP [SC. 11]: auxiliary feature for FPs consisting on echo suppressor for handling the echo 
generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.3. Only narrowband capability is required. 

FP audio type 2 (analogue PSTN 3,1 kHz) [SC.12]: audio specification for a DECT FP supporting narrowband 
service and providing an analogue 2-wire PSTN interface. As defined by EN 300 175-8 [8], clause 7.3.4. 

FP audio type 3 (VoIP 3,1 kHz) [SC. 13]: audio specification for a DECT FP supporting narrowband service and 
providing a VoIP interface, with codecs G.711 (typically) or G.726 on top of it. As defined by EN 300 175-8 [8], 
clause 7.3.5. 

FP audio type 6a (internal call) [SC. 14]: this type of audio specification applies to the case of internal call inside a 
DECT FP or a DECT system without any external interface. This type applies to any service. As defined by 
EN 300 175-8 [8], clause 7.3.8. 

FP audio type 6b (internal conference) [SC. 15]: this type of audio specification applies to the case of 3-party or 
multi-party conference inside a DECT FP or a DECT system with or without an external interface. Applies to any 
service. As defined by EN 300 175-8 [8], clause 7.3.9. 
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Adaptive volume control for FP [SC. 16]: accessory feature for FPs consisting on an adaptive volume control 
depending on the level of environmental noise at the PP. The gain variation should be symmetrical. As described in 
EN 300 175-8 [8], (detailed descriptions for each type of FP in clause 7.6, and examples of settings in informative 
annex D). 

F.2.3 GAP Application features (clause 4.3 of EN 300 444) 

AC to bitstring mapping [A.l]: mapping of the AC into a bitstring. 

multiple subscription registration [A.2]: ability of PP to store more than one subscription. 

manual entry of the Portable Access Rights Key (PARK) [A.3]: ability of the PP to accept a manual entry of the 
PARK for ensuring attachment to the right FP in a physical area covered by many providers. 

terminal identity number assignment in mono-cell system [A.4]: ability to assign to each PT a terminal identity 
number. 

F.2.4 DLC service definitions (clause 5.1 of EN 300 444) 

LAPC class A service and Lc [D.l]: single frame acknowledged C-plane data link service providing a single data link 
between one FT and one PT. 

The higher layer information is segmented (if necessary) and transmitted in numbered frames. The Lc provides frame 
delimiting, transparency and frame synchronization. 

Cs channel fragmentation and recombination [D.2]: Lc service providing channel dependant fragmentation (by 
means of dividing a LAPC data unit into more than one service data units for delivery to the MAC layer C s logical 
channel) and recombination (by means of joining several service units received from the MAC layer C s logical channel 
into a LAPC data unit). 

broadcast Lb service [D.3]: simplex point-to-multipoint transmission using simple fixed length DLC frames providing 
a restricted broadcast service in direction FP to PP(s). 

intra-cell voluntary connection handover [D.4]: internal handover process provided and initiated by the DLC layer 
(e.g. as a result of continued poor quality of service from the MAC layer), whereby one set of DLC entities (C-plane 
and U-plane) can re-route data from one MAC connection to a second new MAC connection in the domain of the same 
cell, while maintaining the service provided to the NWK layer. 

intercell voluntary connection handover [D.5]: internal handover process provided and initiated by the DLC layer 
(e.g. as a result of continued poor quality of service from the MAC layer), whereby one set of DLC entities (C-plane 
and U-plane) can re-route data from one MAC connection to a second new MAC connection not in the domain of the 
same cell, while maintaining the service provided to the NWK layer. 

encryption activation [D.6]: transporting the NWK layer encryption request and the cipher key to the MAC layer, 
thereby enabling the encryption process in the MAC layer. 

LU1 TRansparent Unprotected service (TRUP) class 0/min_delay [D.7]: transparent unprotected service 
introducing minimum delay between the higher layers and the MAC layer. 

May be used for speech and non-speech applications. Speech transmission should only use the class 0/min_delay 
operation over a single bearer MAC connection. Data integrity is not guaranteed. No error protection is applied, and 
octets may be lost, erroneous or duplicated. The continuous higher layer data is fragmented for delivery to the I N logical 
channel in the transmission direction, and recombined from the I N logical channel in the receiving direction. 

FU1 [D.8]: offers a defined fixed length frame structure and buffering functions for transmission of U-plane data to the 
MAC layer (at the transmit side) or accept of data from the MAC layer (at the receiving side) on demand and with 
minimum delay. Used for speech but may be used for more general data purposes. 

encryption deactivation [D.9]: transporting the NWK layer encryption deactivation request to the MAC layer, thereby 
disabling the encryption process in the MAC layer. 
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F.2.5 GAP MAC service definitions (clause 5.2 of EN 300 444) 

general [M.l]: set of basic requirements regarding data formats, multiplexing, CRC usage, scanning and locking, 
which are prerequisites to communication between peer MAC entities. 

continuous broadcast [M.2]: simplex service from FT to PT whereby the FT maintains at least one bearer with 
continuous transmissions. The PT can use the information carried in this bearer to lock to the FT and to obtain 
knowledge about the FT. 

paging broadcast [M.3]: service whereby the identities of specific PTs can be broadcast by the FT. This service is 
normally used by the FT to request a specific PT to set up a link to the FT. 

basic connection [M.4]: service providing connection between FT and PT consisting of one full slot duplex bearer 
supporting the In_minimum_delay data service (i.e. speech). Only one basic connection may exist between a FT and 
particular PT (except during connection handover). The service includes the means for setting-up and releasing the 
required bearer(s). 

C s higher layer signalling [M.5]: low rate connection oriented data service with ARQ using the C s channel to transfer 
higher layer signalling data. 

quality control [M.6]: provides means for monitoring and controlling the radio link quality. 

encryption activation [M.7]: service providing means for enabling the encryption whereby on demand all higher layer 
data (including speech) is transferred across the AI in an encrypted form. Always initiated by the PT. 

extended frequency allocation [M.8]: service which allows a FT to support frequencies in addition to the standard 
DECT frequencies. 

bearer handover - intra-cell [M.9]: internal MAC process whereby data transfer (C channel and I channel) is switched 
from one duplex bearer to another in the domain of the same cell while maintaining the service to the DLC layer. 

bearer handover - inter-cell [M.10]: internal MAC process whereby data transfer (C channel and I channel) is 
switched from one duplex bearer to another not in the domain of the same cell while maintaining the service to the DLC 
layer. 

connection handover - intra-cell [M.ll]: in the MAC layer, it is the process enabling setting up a new basic 
connection in the domain of the same cell to support connection handover at the DLC layer. 

connection handover - inter-cell [M.12]: in the MAC layer, it is the process enabling setting up a new basic 
connection not in the domain of the same cell to support connection handover at the DLC layer. 

Secondary Access Rights Identity (SARI) support [M.13]: ability to support, in addition to the primary Access 
Rights Identity (ARI), secondary ARIs that the FT broadcasts less frequently than PARIs. These may be used to reflect 
an inter-operators agreement allowing a portable to access more than one operator or services through FT. 

encryption deactivation [M.14]: service providing means for disabling the encryption whereby on demand the process 
of transmitting higher layer data (including speech) across the AI in encrypted form is to be cancelled (a connection 
release automatically disables ciphering). 

Re-keying [M.15]: mechanism to change the cipher key during an ongoing call. 

Early encryption [M.16]: mechanism to activate encryption immediately after connection establishment. 
AES/DSC2 encryption [M.17]: encryption using the DSC2 algorithm, based on AES, with Cipher Key of 128 bits. 



F.3 GAP Feature/service to procedure mapping tables 

The following informative annex shows the features/service to procedure mapping tables as defined in EN 300 444 [12] 
(GAP), that are reused in the present document (unless other specification is given). This list is informative, and shows 
the status in EN 300 444 [12] V2.2.1. Where there are changes or divergences the original tables at EN 300 444 [12] 
(GAP) apply. 
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F.3.1 GAP NWK feature to procedure mapping table (clause 6.8.1 
of EN 300 444) 

Table F.1 : NWK feature to procedure mapping (table 5 of EN 300 444) 



Feature supported 





Status 


Item no. 


Name of feature 


Reference 


PT 


FT 










R/B 


P 


N.35 


Outgoing call 


4.1 


M 


M 


M 


N.36 


Off hook 


4.1 


M 


M 


M 


N.37 


^"V 1 1 ft. 1 1 1 \ 

On hook (full release) 


4.1 


M 


M 


M 


N.38 


Dialled digits (basic) 


4.1 


M 


M 


M 


N.39 


Register recall (see notes 4 and 5) 


4.1 


M 


O 





N.40 


Go to DTMF signalling (defined tone length) (see note 1) 


4.1 


M 


O 


M 


N.41 


Pause (dialling pause) (see note 3) 


4.1 


M 


O 


O 


N.42 


Incoming call 


4.1 


M 


M 


M 


N.43 


Authentication of PP 


4.1 


M 


C101 


M 


N.44 


Authentication of user (see note 2) 


4.1 


M 





O 


N.45 


Location registration 


4.1 


M 





M 


N.46 


On air key allocation (see note 2) 


4.1 


M 


C101 


O 


N.47 


Identification of PP 


4.1 


M 





O 


N.48 


Service class indication/assignment 


4.1 


M 





M 


N.49 


Alerting 


4.1 


M 


M 


M 


N.50 


ZAP (see note 2) 


4.1 


M 





O 


N.51 


Encryption activation FT initiated 


4.1 


M 


C101 


M 


N.52 


Subscription registration procedure on-air 


4.1 


M 


M 


M 


N.53 


Link control 


4.1 


M 


M 


M 


N.54 


Terminate access rights FT initiated (see note 2) 


4.1 


M 


O 


O 


N.55 


Partial release 


4.1 


O 





O 


N.56 


Go to DTMF (infinite tone length) 


4.1 


O 








N.57 


Go to Pulse 


4.1 











N.58 


Signalling of display characters 


4.1 











N.59 


Display control characters 


4.1 











N.60 


Authentication of FT 


4.1 











N.61 


Encryption activation PT initiated 


4.1 











N.62 


Encryption deactivation FT initiated 


4.1 











N.63 


Encryption deactivation PT initiated 


4.1 











N.64 


Calling Line Identification Presentation (CLIP) 


4.1 











N.65 


Internal call 


4.1 











N.32 


Service call 


4.1 











N.33 


Enhanced U- plane connection 


4.1 











N.34 


Calling Name Identification Presentation (CNIP) 


4.1 











N.35 


Enhanced security 


4.1 











N.36 


AES/DSAA2 authentication 


4.1 


C102 


C102 


C102 



NOTE 1 : The PT is only required to be able to send the «MULTI-KEYPAD» information element containing the 
DECT standard 8-bit character (EN 300 175-5 [5], annex D) codings "Go to DTMF", defined tone length 
and the FT is required to be able to understand it in the public environment. 



NOTE 2: This feature is required to be supported in the PT to guarantee the same level of security among all the 
handsets that operates in a system. The invocation of the feature is however optional to the operator. 

NOTE 3: The PT is required to be able to send the «MULTI-KEYPAD» information element containing the DECT 
standard 8-bit character (EN 300 175-5 [5], annex D) codings "Dialling Pause". This guarantees 
automatic access to secondary or alternative networks. 

NOTE 4: This feature uses keypad code 15 hex. 

NOTE 5: The FT is not mandated to receive and understand the register recall DECT character. However, if a FT 
supports it there may be no corresponding action that the FT can take with the local network as a result of 

this function. 

C101: IF feature N.35 THEN M ELSE O. 
C102: IF MAC service M. 17 THEN M ELSE O. 
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F.3.2 GAP DLC service to procedure mapping table (clause 6.8.2 
of EN 300 444) 



Table F.2: DLC service to procedure mapping (table 6 of EN 300 444) 



Service/Procedure mapping 




Status 


Service 


Procedure 


Reference 


DT 
K 1 


FT 










K/b 


n 

r 


r~\ A 1 A |~\ /"^ A I A A A A A A # i A A a ia aI 1 A 

U.1 LAro class A service and Lc 




5.1 


ft A 

M 


M 


l\ A 

IVI 


; ; 

Class A link establishment 


y.i 


f\ A 

M 


K A 

M 


i\ a 
M 


Class A acknowledged information 
TransTer 




M 


K A 

M 


l\ A 

M 


Class A link tgIgssg 


y.o 


IVI 


IVI 


IVI 


L/iass m iirirx re-esiaDiisnrneru 


Q /I 


IVI 


IVI 


IVI 


u.£i L»g cnannei Tragmeniaiton ana 
recombination 




^ -i 

0. 1 


IVI 


\A 
IVI 


IVI 


L<g cnannei rragmeniauon ana 
recombination 


y.o 


IVI 


IVI 


IVI 


D.3 Broadcast Lb service 




5.1 


M 


M 


M 


Normal broadcast 


9.6 


M 


M 


M 


D.4 Intra-cell voluntary connection 
handover 




5.1 


M 


C1701 


C1701 


Class A basic connection handover 


9.7 


M 


M 


M 


D.5 Inter-cell voluntary connection 
handover 




5.1 


M 


O 





Class A basic connection handover 


9.7 


M 


M 


M 


D.6 Encryption activation 




5.1 


M 


C1703 


M 


Encryption switching 


9.8 


M 


M 


M 


D.7 LU1 TRUP Class 0/min_delay 




5.1 


M 


M 


M 


U-plane Class 0/min delay 


9.9 


M 


M 


M 


D.8 FU1 




5.1 


M 


M 


M 


FU1 frame operation 


9.10 


M 


M 


M 


D.9 Encryption deactivation 




5.1 


C1702 


C1702 


C1702 


Encryption switching 


9.8 


M 


M 


M 


C1701: IF service M.9 THEN O ELSE M; 
C1702: IF feature N.29 OR N.28 THEN M ELSE I; 
C1703: IF feature N.17 OR N.27 THEN M ELSE I. 



F.3.3 GAP MAC service to procedure mapping table (clause 6.8.3 
of EN 300 444) 



Table F.3: MAC service to procedure mapping (table 7 of EN 300 444) 



Service/Procedure mapping 




Status 


Service 


Procedure 


Reference 


PT 


FT 










R/B 


P 


M.1 General 




5.2 


M 


M 


M 


General 


10.1 


M 


M 


M 


M.2 Continuous broadcast 




5.2 


M 


M 


M 


Downlink broadcast 


10.2 


M 


M 


M 


Higher Layer capability FP broadcast 


13.6 


M 


M 


M 


M.3 Paging broadcast 




5.2 


M 


M 


M 


Paging broadcast 


10.3 


M 


M 


M 


M.4 Basic connections 




5.2 


M 


M 


M 


Setup of basic connection, basic bearer 
setup (A-field) 


10.4 


M 


M 


M 


Connection/bearer release 


10.5 


M 


M 


M 


M.5 C s higher layer signalling 




5.2 


M 


M 


M 


C s channel data 


10.8 


M 


M 


M 


Q2 bit setting 


10.9 


M 


M 


M 
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Service/Procedure mapping 





Status 


Service 


riQCcUUrc 


ncTcicllCc 


PT 


FT 










R/R 
pi d 


p 


IVI.O WUdllLy COiUlOl 




R 9 


M 
IVI 


M 
IVI 


M 
IVI 


nrn iidiiosndrxc 


i u. i u 


M 
IVI 


M 
IVI 


IVI 


Hnienna uiversny 


I U. I I 


i\/i 

IVI 




<~l 


oiiuiny collision uetecTion 


1 n -1 

1 U. 1 £1 




IVI 


IVI 


ivi./ encryption don vdiion 






IVI 


P1 704 


M 
IVI 


encryption process iiiuidiizduon diiu 
cwnph rnn 17a tinn 

oy 1 IOI II U 1 1 1 i-CX L 1 U 1 1 


1 n n 

I U. I o 


IVI 


IVI 


IVI 


L^l IOI y ULIUI 1 1 1 IUUC UUllllUI 


1 u. 1 1 


M 

IVI 


M 


M 


ncii luuvci ciiuiypLiuii piuucoo 


10 1 5 

1 U. 1 \J 


M 


M 


M 


M.8 Extended frequency 
allocation 




R 9 


M 




O 


Fytpnrlprl frpm ipnpv allnpatinn 
1—alci iucu iicu,uciiuy diiuuciiiuii 


m ir 

1 u. 1 u 


M 


M 


M 


M.9 Bearer handover, intra-cell 






M 

IVI 


P1 701 


n 7ni 


Deal CI 1 Idl IUUVCI 1 CL|UCoL 


1 n r 


M 

IVI 


M 


M 


M 1 Rparpr hanrlnvpr intpr-ppll 

IVI.IV/ LJCCll CI 1 lul IUU VUl , III ICI OUl 1 




R 9 


M 








Deal CI 1 lal IUUVCI ICLjUCol 


1 n fi 


M 


M 


M 


IV /I 11 OnnnPf^tirin hanrln\/or intra- 

IVI.I I wUIIIICOLIUII I lal IUU VCl , II I LI d 

cell 




<? 9 

\J.C- 


M 

IVI 


P1 709 


P1 709 


f*~*r»nnpr , tinn hanrln\/pr mm inct 

UUI II ICULIUI 1 1 Idl IUUVCI ICLjUCoL 


1 n 7 

I u. / 


M 

IVI 


M 


M 


y 10 ("^nnnpptinn hanrlnupr intpr- 

I VI . 1 C wUI II ICULIUI 1 1 lal IUUVCI , II 1 LCI 

cell 




5 9 


M 







P.nnnpr'tinn hanrlnvpr rpmip^t 

UUI II ICUIIUI 1 1 1 dl IUUVCI ICLjUCoL 


1 n 7 

I u. / 


M 


M 


M 


M 1 ^ ^ARI Qiinnnrt 

1 VI . 1 O Onni oUUUUI L 




R 9 


M 

IVI 






L/UVVI III 1 ll\ UlUdUUdol 


1 n ? 


M 

IVI 


M 


M 


Hinhpr 1 avpr ranphilitv FP hrnadraQt 

1 1 1 y 1 1 c 1 Lay c 1 \jOLyJoLU\ \ 1 ly 1 1 u 1 uciuucio l 


1 3.6 


M 


M 


M 


M.14 Encryption deactivation 




5.2 


C1703 


C1703 


C1703 


Encryption mode control 


10.14 


M 


M 


M 


M.15 Re-keying 




5.2 


C705 


C705 


C705 


Re-keying 


10.17 


M 


M 


M 


M.16 Early encryption 




5.2 


C706 


C706 


C706 


Early encryption 


10.18 


M 


M 


M 


M.17 AES/DSC2 encryption (see 
note) 




5.2 











AES/DSC2 encryption 


10.19 


M 


M 


M 



NOTE: IF implemented THEN NWK feature N.36 should be implemented. 

C1701: IF service M.11 THEN ELSE M; 

C1702: IF service M.9 THEN ELSE M; 

C1703: IF feature N.29 OR N.28 THEN M ELSE I; 

C1704: IF feature N.17 OR N.27 THEN M ELSE I; 

C705: IF feature N.35 and NWK layer procedure "Re-keying during a call" are implemented THEN M ELSE 0. 

C706: IF feature N.35 and NWK layer procedure "Early encryption" are implemented THEN M ELSE O. 



F.3.4 GAP Application feature to procedure mapping table 
(clause 6.8.4 of EN 300 444) 



Table F.4: Application feature to procedure mapping table (table 8 of EN 300 444 [12]) 



Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 










R/B 


P 


A.1 AC to bitstring mapping 




4.3 


M 


C1701 


M 


AC to bitstring mapping 


14.2 


M 


M 


M 


A.2 Multiple subscription 
registration 




4.3 


M 


N/A 


N/A 


Subscription control 


14.1 


M 


N/A 


N/A 


A.3 Manual entry of the PARK 




4.3 





N/A 


N/A 


Manual entry of the PARK 


14.3 


M 


N/A 


N/A 


A. 4 Terminal identity number 
assignment in mono cell system 




4.3 








N/A 


Terminal identity number assignment 


14.4 








N/A 


C1701 : IF feature N.9 OR N.10 OR N.12 OR N.26 THEN M ELSE N/A. 
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Annex G (informative): 
Recommended best practices 

G.1 Summary of best practices for implementation of first 
outgoing voice calls 

Tables G. 1 and G.2 summarize the recommended best practice for NG-DECT Part 3 PPs and NG DECT Part 3 FPs 
concerning the implementation of first outgoing external and internal calls. 

The early and non early CC-CONNECT implementations are described more in details in clause 7.4.6.4.6. 



Table G.1 : Possible scenarios for a NG-DECT Part 3 FP regarding first outgoing external voice call 



Mechanism 


Non early CC-CONNECT implementation 


Early CC-CONNECT implementation 


External call (without prior list acc 


3SS) 




Selection of the line by the PP 


CC-SETUP + Call Information IE with Line 

id 

or 

CC-INFO (Call Information or Multikeypad 
(#Line Id)) 


CC-SETUP + Call Information IE with 

Line id 

or 

CC-INFO (Call Information or 
Multikeypad (#Line Id)) 


Answer to CC-SETUP from the 
FP 


CC-SETUP-ACK (note 1) 


CC-CONNECT 


Sending of digits from the PP 


One or several CC-INFO + IE 
MULTIKEYPAD (note 2) 


One or several CC-INFO + IE 
MULTIKEYPAD 


Call Id assignment by FP 


In CC-SETUP-ACK 


In CC-CONNECT (recommended way) 
or CC-INFO before CC-CONNECT 


Line Id confirmation by FP 


In CC-SETUP-ACK if Line Id was sent in 
CC-SETUP 

CC-INFO or CC-CALL PROC otherwise. 


In CC-CONNECT or further CC-INFO 


Call statuses from FP 


Corresponding call status sent in each CC 
message until CC-CONNECT (note 4) 


Sent in further dedicated CC-INFO 
messages after CC-CONNECT 
(note 5). 


External call (with prior established list access using Cs) 


Selection of the line by the PP 


CC-INFO (same as the one with digits) + Line information 


Sending of digits from the PP 


One CC-INFO + IE MULTIKEYPAD (note 3) 


Message back from FP 


CC-CONNECT (after CC-CALL-PROC) 


Call Id assignment by FP 


In one further CC-INFO message after CC-CONNECT 


Line Id confirmation by FP 


In one further CC-INFO message after CC-CONNECT 


Call statuses from FP 


In further CC-INFO messages after CC-CONNECT 


NOTE 1 : For sending digits, NG-DECT Part 3 inherits the rules mandated by the GAP [1 2] profile. Therefore only CC- 
INFO with multikeypad should be used (no more digits sent in CC-SETUP). As a consequence, the CC- 
SETUP-ACK should be de-facto used by the FP as systematic answer to the CC-SETUP for non early CC- 
CONNECT implementations. 

NOTE 2: For sending digits, both en-bloc and piecewise dialling methods are possible. Corresponds to "pre/post 
dialling" done on handset. 

NOTE 3: For sending digits when a list access session is priori established, only en-bloc method is supported. 
NOTE 4: Sending of call statuses in non early CC-CONNECT implementations (for example Call status 'CS call setup 

ack') is done by using the CC-SETUP-ACK message. 
NOTE 5: Sending of call statuses in early CC-CONNECT implementations (for example Call status 'CS call setup ack') 

is done by using a dedicated CC-INFO message. 
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Table G.2: Possible scenarios for a NG-DECT Part 3 FP and PP regarding first 

outgoing internal voice call 



Mechanism 


Non early CC-CONNECT implementation 


Early CC-CONNECT implementation 




Answer to CC-SETUP from the 
FP 


CC-SETUP-ACK (note 1) 


CC-CONNECT 


Sending of digits from the PP 


One CC-INFO + IE MULTIKEYPAD (note 2) 


One CC-INFO + IE MULTIKEYPAD 
(note 2) 


Call Id assignment by FP 


In CC-SETUP-ACK 


In CC-CONNECT (recommended way) 
or CC-INFO before CC-CONNECT 


Call statuses from FP 


Corresponding call status sent in each CC- 
message (until CC-CONNECT) 


Sent in further dedicated CC-INFO 
messages after CC-CONNECT 
(note 5). 


Internal call (with prior established list access on Cs) 


Sending of digits from the PP 


One CC-INFO + IE MULTIKEYPAD (note 3) 


Message back from FP 


CC-CONNECT (after CC-CALL-PROC) 


Call Id assignment 


In one further CC-INFO message after CC-CONNECT 


Call status 


In further CC-INFO messages after CC-CONNECT 


NOTE 1 : For sending digits, NG-DECT Part 3 inherits the rules mandated by the GAP [12] profile. Therefore only CC- 
INFO with multikeypad should be used (no digits sent in CC-SETUP). As a consequence, the CC-SETUP- 
ACK should be de-facto used by the FP as systematic answer to the CC-SETUP for non early CC-CONNECT 
implementations. 

NOTE 2: For sending digits in internal calls, only en-bloc dialling method should be used. 

NOTE 3: For sending digits when a list access session is priori established, only en-bloc dialling method should be 
used. 

NOTE 4: Sending of call statuses in non early CC-CONNECT implementations (for example Call status 'CS call setup 

ack') is done by using the CC-SETUP-ACK message. 
NOTE 5: Sending of call statuses in early CC-CONNECT implementations (for example Call status 'CS call setup ack') 

is done by using a dedicated CC-INFO message. 
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Annex H (normative): 
Editable fields 

The following tables summarize the status of the "editable" property for each field defined in the present document. The 
status of the "editable" property of a field may be: 

• "YES"; in that case the field "editable" property shall always be set by the FP. 

• "NO"; in that case the field "editable" property shall always be unset by the FP. 

• "MD" (for "Manufacturer Defined"); in that case the FP may choose between the following behaviours for the 
"editable" field: 

the field "editable" property is always set by the FP (as with "YES"); 
the field "editable" property is always unset by the FP (as with "NO"); 

the field "editable" property value varies with time; if the FP decides to modify the "editable" property 
value of a field in the list at some point in time the FP shall send a "list change notification" to the PP 
(see clause 7.4.10.2) in order to notify this change, but only if the following two conditions are met: 

■ at least one field instance concerned by this change exists in an entry of the list at this point in time; 

■ the "list change notification" is mandatory for the considered list (see clause 7.4.10.2.2), or the FP 
implementation sends notifications for other entry modifications of the list. 

EXAMPLE 1: Depending on the configured user profile, the field is either "editable" or not. Especially, some 

critical fields could be only editable for experienced users. A web interface could be used in order 
to configure the FP and choose among different user profiles with related sets of editable fields. 

The field "editable" property value depends on the entry, or even on the field instance in the entry, for a 
given list. 

EXAMPLE 2: Some implementations may provide non-editable Contact List entries (e.g. for emergency calls), 
while other Contact List entries are fully editable; see also clause 7.4.10.4.2.2. 



Table H.1 : "Editable" status in the List of Supported Lists 



Field id 


Field 


Clause 


Editable 


01H 


List identifiers 


7.4.10.5.1.1 


NO 


Table H.2: "Editable" status in the Missed Calls List 


Field id 


Field 


Clause 


Editable 


01H 


Number 


7.4.10.5.1.2 


NO 


02H 


Name 


7.4.10.5.1.3 


NO 


03H 


Date and Time 


7.4.10.5.1.4 


NO 


04H 


Read status 


7.4.10.5.1.5 


YES 


05H 


Line name 


7.4.10.5.1.6 


NO 


06H 


Line id 


7.4.10.5.1.7 


NO 


07H 


Number of calls 


7.4.10.5.1.8 


NO 
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Table H.3: "Editable" status in the Outgoing Calls List 



Field id 


Field 


Clause 


Editable 


01H 


Number 


7.4.10.5.1.2 


NO 


02H 


Name 


7.4.10.5.1.3 


NO 


03H 


Date and Time 


7.4.10.5.1.4 


NO 


04H 


Line name 


7.4.10.5.1.6 


NO 


05H 


Line id 


7.4.10.5.1.7 


NO 


Table H.4: "Editable" status in the Incoming Accepted Calls List 


Field id 


Field 


Clause 


Editable 


01H 


Number 


7.4.10.5.1.2 


NO 


02H 


Name 


7.4.10.5.1.3 


NO 


03H 


Date and Time 


7.4.10.5.1.4 


NO 


04H 


Line name 


7.4.10.5.1.6 


NO 


05H 


Line id 


7.4.10.5.1.7 


NO 


Table H.5: "Editable" status in the All Calls List 


Field id 


Field 


Clause 


Editable 


01H 


Call type 


7.4.10.5.1.9 


NO 


02H 


Number 


7.4.10.5.1.2 


NO 


03H 


Name 


7.4.10.5.1.3 


NO 


04H 


Date and Time 


7.4.10.5.1.4 


NO 


05H 


Line name 


7.4.10.5.1.6 


NO 


06H 


Line id 


7.4.10.5.1.7 


NO 


Table H.6: "Editable" status in the Contact List 


Field id 


Field 


Clause 


Editable 








(note) 


01H 


Name 


7.4.10.5.1.3 


MD 


02H 


First name 


7.4.10.5.1.10 


MD 


03H 


Contact number 


7.4.10.5.1.11 


MD 


04H 


Associated melody 


7.4.10.5.1.12 


MD 


05H 


Line id 


7.4.10.5.1.7 


MD 


NOTE: For user-defined contact entries (most contact entries), the "editable" 


property shall be set for all fields (as with "YES"). For manufacturer 


defined entries (e.g. emergency call number), the "editable" property 


could be unset. 







Table H.7: "Editable" status in the Internal Names List 



Field id 


Field 


Clause 


Editable 


01H 


Number 


7.4.10.5.1.2 


NO 


02H 


Name 


7.4.10.5.1.3 


YES 


03H 


Call interception 


7.4.10.5.1.13 


MD 
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Table H.8: "Editable" status in the "DECT System Settings List" 



Field id 


Field 


Clause 


Editable 


\j i n 


Oiirront PIM rnrlo 
OUIIclll r UN OUUc 


7 4 11 1 1 

/ .H. I I .O. I 


T LO 

(note 1) 




C >t \r\r t \iC m Qcto r 
OlUOft 1 1 IdbLol 


7 4 11 19 

/ .H . 1 1 .O.C. 


yn 

IVI LJ 


03H 


Base reset 


7.4.11.3.3 


YES 


C\A U 
U4H 


FP IP address / type 


7 A 11 Q A 
1 .4.1 1 .0.4 


iv /in 
IVIU 


Uon 


FP IP address / value 


7/1 11 Q £ 


iv /in 
IVIU 

fnntp 0\ 
\\ iuit; c.) 


uon 


PP IP arlrlrocc / ci ihnat mocl/ 
rr li aUUIcoo / bUUlltJl 1 1 ldor\ 


7 4 11 T fi 

/ .H. I I .O.D 


yn 

IVI u 

fnntp 2) 

II IU It/ t— } 


07H 




7.4.1 1 .3.7 


MD 
(note 2) 


08H 


FP IP address / DNS server 


7.4.11.3.8 


MD 
(note 2) 


09H 


FP version / Firmware version 


7.4.11.3.9 


NO 


OAH 


FP version / Eeprom version 


7.4.11.3.10 


NO 


OBH 


FP version / Hardware version 


7.4.11.3.11 


NO 


OCH 


Emission mode 


7.4.11.3.12 


YES 


ODH 


New PIN code 


7.4.11.3.13 


YES 


NOTE 1 : The "Current PIN code" is only used for checking the PIN value entered 

by the user. Edition of this field does not modify the field value. 
NOTE 2: The field is editable only for a static IP address. 


Table H.9: "Editable" status in the "Line Settings List" 


Field id 


Field 


Clause 


Editable 


01H 


Line name 


7.4.11.4.1 


MD 


02H 


Line id 


7.4.11.4.2 


NO 


03H 


Attached handsets 


7.4.11.4.3 


MD 


04H 


Dialling prefix 


7.4.11.4.4 


YES 


05H 


FP melody 


7.4.11.4.5 


YES 


06H 


FP volume 


7.4.11.4.6 


YES 


07H 


Blocked telephone number 


7.4.11.4.7 


MD 


08H 


Multiple calls mode 
(single/multiple) 


7.4.11.4.8 


MD 


09H 


Intrusion call 


7.4.11.4.9 


MD 


OAH 


Permanent CLIR 


7.4.11.4.10 


MD 


OBH 


Call forwarding unconditional 


7.4.11.4.11 


MD 


OCH 


Call forwarding on No answer 


7.4.11.4.12 


MD 


ODH 


Call forwarding on Busy 
subscriber 


7.4.11.4.13 


MD 


Table H.10: "Editable" status in the All Incoming Calls List 


Field id 


Field 


Clause 


Editable 


01H 


Number 


7.4.10.5.1.2 


NO 


02H 


Name 


7.4.10.5.1.3 


NO 


03H 


Date and Time 


7.4.10.5.1.4 


NO 


04H 


Read status 


7.4.10.5.1.5 


YES 


05H 


Line name 


7.4.10.5.1.6 


NO 


06H 


Line id 


7.4.10.5.1.7 


NO 


07H 


Number of calls 


7.4.10.5.1.8 


NO 
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